best practices on hub tunnel settings in large installations

Discussion created by chris.luekermann on Oct 13, 2010
Latest reply on Dec 6, 2017 by Daniel Blanco


here's something 1&1 identified in the hub tunnel settings that had a huge effect on the performance of their hub/tunnel setup.


They were facing the fact that tunnel connections seemed to be quite instable and the message flow was fluctuating periodically.


First of all, they increased the Tunnel Session Pool from 5 (default) to 30 in order to increase the throughput of the tunnels. Something you will probably do as well I assume once the installation has to handle large volumes of messages.

This did increase the throughput but also caused the system to become more instable.

Now, the trick - is to also adapt the Server Cache Size of the hub (you find all those settings in the hub under the advanced-tab). The Cache Size is set to 1024 by default. Now this is fine if you do not have a lot of tunnels with a lot of connections - but if you do, you need to increase this value.

The formula to calculate the correct server cache size for the hub is:
<number of tunnels / known hubs> x <Tunnel Session Pool> x 2 = Server Cache Size

The reason why you have to multiply it with 2 is that you configure the session pool for one direction only, the hub creates twice the amount of connections though, the incoming and the outgoing ones.

Once these settings were made the message flow is totally even and we do no longer have weird disconnects.


Something else to watch out for is to not set the SSL_Reconnect-times and timeouts too short. By default those are quite high and 1&1 is using 180 seconds as the tunnel timeouts - setting those lower seemed to thrash the system once the network went down for a couple of minutes.



ps: if you think these settings are wrong - let me know. we figured those out by analyzing the tcp traffic and they work just fine for a couple of weeks now but they were not officially suggested by our R&D.