Azure Servicebus继电器性能

我正在使用带有nettcprelaybinding的服务总线。一方是OnPremise服务器，它与服务总线有恒定的连接。另一方面，Azure Web角色通过打开相应的服务总线并从服务器获取信息来响应传入的Web请求。Azure Servicebus继电器性能

我担心的是渠道创作的表现。通过服务总线建立到服务器的新连接需要几秒钟的时间。缓存我的ChannelFactory似乎没有多大帮助。频道开放后的转播表现非常好。

关于如何提高性能的任何建议。在Azure中缓存信息只能在一定程度上完成。我需要连接到onpremise服务器。

我可以以某种方式建立到服务总线的连接池吗？

关于更多的事情，有许多不同的onpremise服务器，所以它不只是一个连接来保持活力。

来源

2012-04-03 user1284390

您应该可以将连接池，但Azure负载平衡器将terminate any open connection that sits idle for more then 60 seconds。因此，如果您将连接缓存的时间比调用之间的连接时间要长，则需要实施某种心跳模式以帮助保持连接的活跃状态。

另一个可能需要考虑的选项是Azure Connect。这使您可以创建从云托管资源到本地服务器的IPsec点到点连接。它确实需要将客户端安装在您想要连接的本地箱上，但有些客户一直使用它来建立到本地代理服务的简单网关连接。

来源

2012-04-03 10:54:26 BrentDaCodeMonkey

感谢您的好评。不知道60秒的限制。如果我想集中连接。什么是这样做的好方法？我通过以下链接找到了一些信息（http://code.msdn.microsoft.com/WCF-Azure-NetTCP-Keep-Alive-09f50fd9）。但是，这是多实例Azure环境中的优秀解决方案吗？如果一个通道在一个实例上打开并且下一个客户端在另一个实例上执行？还是负载平衡器确保使用相同的实例？ – user1284390 2012-04-03 16:53:38

据我了解，每个实例都有自己的连接。而且，由于它们保持打开状态，因此您需要了解单个命名空间允许的最大连接限制（2000或某些我认为的限制）。如果它的好坏取决于你对性能和可扩展性的需求。 – BrentDaCodeMonkey 2012-04-03 18:09:15

这有点旧 - 但仅供参考，似乎大多数Azure LB现在都是基于软件的，并且默认超时时间为4分钟（而现有的基于硬件的LB不超过1分钟） - 现在可以配置。但是，目前还不清楚Service Bus客户端库是否自动为您实现TCP KeepAlive，因此LB超时并不是真正的问题：https：//azure.microsoft.com/en-us/blog/new-configurable-idle-timeout-for-azure-load-balancer/ – Jmoney38 2018-01-09 03:28:09

我是微软Service Bus团队的成员。与发送消息相比，打开连接的成本很高，因为需要多方通信才能确保双方互相通话。

对此的缓解是缓存频道而不是缓存ChannelFactory。有NetTcpRelayBinding连接执行的后台保持活动ping应确保通道保持打开状态。

来源

2012-04-04 20:57:13

在WCF中，我必须注意故障通道，并在发生异常时重新创建代理。服务总线在这方面是否类似？我应该如何处理缓存客户端的Service Bus中的异常？ – LamonteCristo 2012-04-05 16:45:24

再次感谢您的所有反馈。从网站角色的角度来看，任何人都可以指引我推荐缓存中继频道的方式吗？我会在每个Web角色实例上缓存通道，还是可以使用可以在实例中使用的Azure缓存？ makerofthings7：我想你可以像处理“正常”的WCF一样处理异常，但请记住，这只与两个连接中的一个有关。 Servicebus需要连接，每边一个。所以如果一个坏了，另一个不会自动通知我的知识。 – user1284390 2012-04-06 15:35:42

Azure Servicebus继电器性能

回答

相关问题