Azure Servicebus relay performance

Question

I'm using the service bus with nettcprelaybinding. One one side is OnPremise server that has a constant connection to the service bus. On the other end is a Azure web role that responds to incoming web requests by opening the appropriate service bus and fetch information from server.

My concern is the performance of the channel creation. It takes a couple of seconds to establish a new connection to the onpremise server through the service bus. Caching my ChannelFactory doesn't seem to help much. The transfer performance after the channel is open is very good.

Any suggestions on how to improve the performance. Caching information in Azure can only be done to some extent. I need to connect to the onpremise server.

Can I somehow establish a connection pool to the service bus?

On more thing, there are a number of different onpremise servers so it isn't just one connection to keep alive.

Nisbet

Answer 1

I'm a member of the Service Bus team at Microsoft. The cost of opening a connection is high in comparison to sending messages because of the multiple communications necessary to get both sides to ensure they are talking to each other.

The mitigation for this is to cache a channel rather than caching a ChannelFactory. There are background keep-alive pings performed for NetTcpRelayBinding connections that should ensure the channel stays open.

Binary

In WCF I have to pay attention to faulted channels, and recreate the proxy if an exception occurs. Is the Service Bus similar in this regard? How should I handle exceptions in the Service Bus with the cached client? – Shyster

Thanks again for all feedback. From a web role point of view, can anyone point me towards a recommended way of caching relay channels? Would I cache channels on each web role instance or could I perhaps use Azure cache that could be used among instances? makerofthings7: I guess you can handle the exception as with "normal" WCF but keep in mind that this is only related to one out of two connections. Servicebus takes to connections, one from each side. So if one goes bad the other isn't automatically notified to my knowledge. – Nisbet

Answer 2

You should be able to pool the connections, but the Azure load balancers will terminate any open connection that sits idle for more then 60 seconds. So if you are caching the connection longer than that between calls, you'll need to implement some kind of heartbeat pattern to help keep the connection alive.

Another option you may want to consider is Azure Connect. This allows you to create a ipsec point to point connection from cloud hosted resources to an on-premises server. It does require a client be installed on the on-premises boxes you want to connect too, but some have been using it to establish a simple gateway connection to an on-premise proxy service.

Banger

Thanks for the good feedback. Didn't know about the 60 second limit. If I want to pool the connections. What's a good way of doing that? I found some info on it by following your link (code.msdn.microsoft.com/WCF-Azure-NetTCP-Keep-Alive-09f50fd9). But is this the good solution in a multi-instance Azure environment? If a channel is open on one instance and the next client is executed on a different instance? Or does the load balancer make sure that the same instance is used? – Nisbet

As I understand it, each instance gets its own connection. And since they are keeping them open, you need to be aware of the maximum connection limits (2000 or some such I believe) that are allowed on a single namespace. If its good or bad to do this believe depends on your needs for performance and scaleability. – Banger

This is a bit old - but just FYI, seems like most Azure LBs are now software-based, and have a default timeout of 4 minutes (not 1 min with the prior hardware-based LBs) - and this is configurable now. However, it's unclear to me, at this moment, if Service Bus client library is implementing TCP KeepAlive for you automatically, and hence an LB timeout is not really an issue: azure.microsoft.com/en-us/blog/… – Mesic