Solution
The MAX_CONNECTIONS setting
This setting exists for both servers and agents.
SERVER
The current Server-side default is 2000 connections
The 2000 connection limit per server is rarely modified, since as system activity grows, it’s often accompanied by the customer shifting from using a single-server system to scale horizontally with a clustered architecture. For example, a 3-node cluster would be able to handle 6000 connections in total, and thus would rarely face it’s limits on any 1 of the 3 servers.
One example of a time where this number of connections could create a bottleneck is in environments that have multiple thousands of end point agents to connect with.
The Ping-All operation will (by default) launch approximately once per hour.
With this many end points to connect with, each request can take seconds to complete, so running out of connections for a short time period is a pattern that can arise, (these pings will simply backlog, as will new requests for work).
So raising this connection count perhaps to 3000, can often help to mitigate this risk.
AGENT
The current agent-side default is 200 connections.
The agent-side MAX_CONNECTIONS setting of 200 is rarely going to require an increase. Perhaps if you were using an nndpoint with a very large number of core and running 100s of concurrently active steps, then updating this property may be necessary. Generally such "super-hosts" are less likely when VMs and containers are becoming the more popular model of distributing workloads.
The MAX_CONNECTIONS_PER_ROUTE setting
This is an agent-side setting only.
The default value for this setting is 20.
This setting is relevant whenever you are have defined an agent to act as a Gateway node. The agent in Gateway scenarios is being used to pass data through itself, possibly communicating with a number of different endpoint agents. Updating this value to reflect such a 1:many fan-out should be considered when initially setting up your gateway. This decision should be based on the number of endpoints you envision using behind this gateway in the foreseeable future.
Since a gateway configuration exists in pairs, such that there is one gateway sitting in the default zone as well as on the edge of the destination zone, updating this value on both involved agents is required.
If you are concerned that your gateway may be creating a bottleneck, despite having increased this default, then please contact CloudBees Support for further guidance.