Azure Servicebus Relay Performance

Question

I am using a service bus with nettcprelaybinding. One of the parties is the OnPremise server, which has a permanent connection to the service bus. At the other end, there is an Azure web role that responds to incoming web requests by opening the corresponding service bus and retrieving information from the server.

I am concerned about the performance of creating a channel. It takes a few seconds to establish a new connection to the onpremise server via the service bus. Caching my ChannelFactory doesn't seem to help much. The transmission efficiency after opening the channel is very good.

Any suggestions for improving performance. Caching information in Azure is only possible to a certain extent. I need to connect to the onpremise server.

Is it possible to somehow install the connection pool on the service bus?

Moreover, there are many different onpremise servers, so not only one connection can be supported.

Answer 1

I am a member of the Service Bus team at Microsoft. The cost of opening a connection is high compared to sending messages because of the multiple messages required for both parties to ensure that they talk to each other.

The mitigation for this is channel caching, not ChannelFactory caching. To keep NetTcpRelayBinding connected, keep-alive background signals are executed to ensure that the channel remains open.

Answer 2

You should be able to combine the connections, but the Azure balancers will terminate any open connection that has been idle for more than 60 seconds . Therefore, if you cache the connection longer than between calls, you will need to implement some kind of heart rate pattern to keep in touch.

Another option you might consider is Azure Connect. This allows you to create an ipsec point to point connection from cloud resources to the local server. It requires the client to be installed in the local mailboxes that you want to connect, but some of them used it to establish a simple connection with the gateway to the local proxy service.