Persistent connections limitations and scaling

I really like the idea of persistent connections. This will really help us in our environment because the UDP packets are not permitted though firewalls.

I noticed that the default limits seem rather low, only 100 persistent connections per relay. There are not any numbes published on the limits of number of devices with persistent connections to each relay before an impact to performance.

https://www.ibm.com/support/knowledgecenter/SSQL82_9.5.0/com.ibm.bigfix.doc/Platform/Config/r_client_set.html#r_client_set__perc

We would like to enable persistent connections on all devices in our environment. Are there any numbers with how many devices persistent connections have been tested with? We would potentially have about 5000 devices with persistent connections with 500-1000 devices per relay.

I was wondering if there was any published information on how many devices have been tested with persistent connections.

Hi,

The point of persistent connections (as outlined here: https://www.ibm.com/support/knowledgecenter/en/SSQL82_9.5.0/com.ibm.bigfix.doc/Platform/Config/c_persistenconn.html) is to enable a small subset of clients on a network to distribute UDP packets to other clients on that network.

This allows UDP notifications to not have to traverse a network firewall (because they are always coming from a client on the same subnet).

Bill

1 Like

Unfortunately our environment is not quite that simple in terms of networking. We are a managed services provider and have many small/medium customers. Each customer has their own firewall and most have multiple zones with a couple servers in that zone. We will not be easily able to pick and choose which hosts to have persistent connections so we will need to enable persistent connections on the while environment. The UDP traffic is not permitted on any of the firewalls.

That is why I am looking for some numbers on the max number of persistent connections per relay.

Sort of a side question here, but there are 500 clients on a subnet and _BESRelay_PersistentConnection_NumberPerSubnet is left at the default of 3, there is no risk of enabling _BESClient_PersistentConnection_Enabled on all 500 clients because only 3 persistent connections will be allowed to the Relay?

Which 3 clients connections are allowed?

any input or ideas on the max number of persistent connections that we should allow to a relay?

The default value of 100 seems very low. Will there be performance issues if we increase that value?

Sorry I see there are a couple of posts here awaiting responses.

For reference the documentation is at https://www.ibm.com/support/knowledgecenter/en/SSQL82_9.5.0/com.ibm.bigfix.doc/Platform/Config/c_persistenconn.html

@bcoleman, whether increasing the persistent connection limit slows your relay will depend a lot on your relay’s characteristics. If you have dedicated relays, I’d recommended looking into the Scalability Guide and performing the configurations for a “High-volume relay”, which mostly involves tuning parameters in the TCP stack to allow faster reuse of sockets and expanding the range of ephemeral ports allowed on the relay host. Check the guide linked at https://www.ibm.com/developerworks/community/wikis/home?lang=en#!/wiki/Tivoli%20Endpoint%20Manager/page/Performance%20&%20Capacity%20Planning

Once you’ve configured relay scalability, feel free to experiment with increasing the persistent connection limits and monitor the deployment for results. Please let us know how it works out for you, it’s always good to hear real-world feedback.

@cstoneba, once Persistent Connections are enabled at the relay and the client, the first 3 clients from any subnet to request a Persistent Connection are granted one. Before a persistent connection is established, the Relay sends a UDP notification to the client. If the client receives the UDP notification, it determines that the persistent connection is not necessary and does not establish one. Once a client does establish a persistent connection, it acts as a UDP message forwarder to other clients on its local subnet, so those other clients will receive the UDP messages. A single client with a persistent connection is enough to bring UDP visibility to its entire subnet, we just enable three by default to provide some redundancy; all three forward UDP notifications, so the other clients are less likely to miss a message if one of the forwarding clients is rebooted.

What has been working well for me with several customers is to enable persistent connections on all relays and all clients. Only the subnets that need persistent connections (because UDP is blocked by NAT or firewall rules) establish persistent connections at all, and the “local” clients where UDP is working don’t need or use the persistent connections.

Another note on relay scaling in general, is that the relays are often limited by available network sockets more than processor, RAM, or disk I/O; so an effective technique for some is to put multiple Relays as virtual machines on a single physical host. It’s a way to scale up network sockets without spending on more physical hardware (each virtual relay should have sufficient space for caching being the main cost factor).