In most load-balancing designs the connection limit is treated as a single field: how many connections can be open at once? That model is incomplete. Ten thousand pending keep-alive connections may be cheap, while 1,000 simultaneous new SSL handshakes can rapidly exhaust backend CPU. The same number produces entirely different cost depending on the traffic type.
Connection count and connection rate are also not the same thing. "Up to 20,000 connections can be open at once" is a capacity ceiling; "up to 10,000 new connections can be opened per second" is burst and connection-storm control. Systems that do not separate these two values either unnecessarily constrain legitimate user traffic or fail to protect the backend from a sudden attack wave.
TLS traffic must be considered separately. SSL/TLS handshake operations are CPU-expensive, and when managed under the same limit as plain HTTP connections the true load becomes invisible. Especially during public web, API gateway and campaign-period traffic, independently capping the handshake rate keeps backend CPU consumption under control.
Queue behaviour is also often opaque. When a limit is exceeded, is the connection silently dropped, does it time out, does it wait in a queue, or does the client get a clean 503? Without visibility into that behaviour, root cause is not clear at incident time — users see a timeout, and the operations team identifies the real reason too late.
TR7 Pool Connection Limits protect backend services through predictable capacity management rather than silent overload, by independently controlling total connections, connection rate, session rate, SSL load, buffer budget and retry behaviour.
TR7 manages pool capacity not with a single field but with a profile structure built across connection, rate, SSL, retry and buffer axes.
A single profile defines maxConn, maxRetries, rateLimitSessions, maxConnRate, maxSessRate, maxSslConn, maxSslRate and maxBufferSize. This lets the backend's connection, rate, TLS and memory limits be tuned independently from one another.
Because TLS handshakes are CPU-expensive, TR7 manages maxSslConn and maxSslRate as distinct values. This separation helps prevent a handshake storm from exhausting the backend even when the total connection count appears low.
A limit profile is defined with a unique name and can be attached to different service pools. Production, staging, canary or per-tenant capacity policies can all be managed with a single profile model.
maxRetries defines how many times a connection to the backend is retried on transient failure. maxBufferSize controls per-connection memory consumption in slow-client or slow-backend scenarios.
TR7 Pool Connection Limits constrain backend services in a controlled way against connection storms, TLS load, session bursts and memory pressure.
maxConn sets the ceiling for simultaneously open connections per pool, with a default of 20,000 and an upper bound of 1,000,000. This value encodes at the ADC layer exactly how many connections the backend can carry at once. When the limit is reached, new connections are subject to queue behaviour or a rejection flow.
maxConnRate limits the number of new TCP connections that can be opened per second, defaulting to 10,000. Unlike total connections, this field governs the rate at which connections are opened. It helps prevent the backend from being overwhelmed in a single burst during connection storms, aggressive scanning or misbehaving load tests. It is a critical burst-protection control for public-facing services.
maxSessRate applies a per-second ceiling to new sessions, defaulting to 10,000. Reusing keep-alive connections and repeatedly opening new sessions carry different costs. This distinction is useful particularly against cookie-based session-opening storms or bot behaviour that exhausts application sessions. Traffic is constrained not only by connection count but also by the rate at which sessions are produced.
rateLimitSessions provides a separate per-second control for new connection slot allocation, defaulting to 5,000. It is used to manage new connection acceptance behaviour with finer granularity. It helps the pool advance at a controlled capacity during sudden connection bursts. The relationship between backend capacity and ADC acceptance rate is tuned more precisely.
maxSslConn defines a separate concurrent-connection limit for active SSL/TLS connections, defaulting to 5,000. TLS connections must be treated differently from plain connections because of CPU, memory and cryptographic processing cost. This limit more accurately reflects the backend's real capacity on the TLS side. It simplifies SSL capacity planning, especially for public web and API traffic.
maxSslRate caps the number of SSL/TLS handshakes that can be initiated per second, defaulting to 2,000. Handshake operations can carry high cost depending on RSA or ECDSA usage, key size and CPU capacity. This field helps prevent TLS handshake storms from exhausting backend CPU. It provides more meaningful protection than a plain-connection limit during DDoS or aggressive bot traffic.
maxBufferSize sets the buffer size available per connection in KB, defaulting to 128 KB with a range of 16–256 KB. Memory consumption is controlled by this value for slow clients, slow readers or requests carrying large bodies. The field provides operational protection against Slowloris-like behaviour and memory pressure.
maxRetries defines how many times the backend connection is retried on failure, defaulting to 3 with an upper bound of 1,000. A lower value provides fast error return; a higher value can improve resilience during transient network blips. However, excessive retries can add load to an already struggling backend and must be chosen carefully.
A limit profile is defined with a unique name and can be assigned to multiple pools. Editing a single profile changes the connection behaviour of all pools bound to it. This model reduces the need to configure each service pool individually. Production, test, campaign or per-tenant profiles can each be managed independently.
When a limit is exceeded, connections can wait in a queue up to a defined depth. When the queue fills, the client receives a clear error rather than a silent timeout. Operations teams can identify when a capacity ceiling is reached more quickly through explicit error signals such as 503. The problem becomes a measurable capacity event rather than an ambiguous user-side wait.
Pool connection limits must be planned together with default values, zero-disable behaviour, global/frontend/pool generation and memory budget.
The default model uses maxConn 20K, maxRetries 3, rateLimitSessions 5K, maxConnRate 10K, maxSessRate 10K, maxSslConn 5K, maxSslRate 2K and maxBufferSize 128 KB. These are starting points. Real tuning must be done according to backend capacity, TLS cost and traffic pattern.
All limit fields accept 0 as their minimum value. This can be used for scenarios where a given control should be disabled or behave as unlimited. In production, however, a value of 0 should be set deliberately — otherwise the expected protection is removed.
maxConn can be set as high as 1,000,000. This provides flexibility for very high-density keep-alive or connection pool scenarios. Even so, real capacity is not determined by this number alone — file descriptors, memory, CPU, TLS cost and backend limits must all be accounted for together.
maxBufferSize directly affects per-connection memory consumption. A lower value increases memory protection, but may introduce compatibility issues for applications with large bodies or slow streams. The 16–256 KB range allows a controlled trade-off between security and application needs.
Profile values are reflected across global, frontend and pool-level connection behaviour. This separation allows the overall device capacity and the capacity of a specific pool to be managed independently. In large deployments, total ADC capacity and single-pool capacity must not be conflated.
SSL connection limits are linked to TLS bind behaviour. Values such as maxSslConn enable TLS connections to be managed separately from plain connections. This is important for protecting CPU budget in public-facing services where TLS traffic is heavy.
An e-commerce platform running a 20K-connection profile on normal days can switch to a higher-connection profile during a campaign period. The same pool is kept; only the limit profile is changed to prepare for campaign traffic.
A bank can allow a high total connection count on its internal API pool while keeping the SSL connection and handshake rate narrower. This structure controls TLS cost and protects backend CPU from sudden handshake load.
On an internet-facing web application, bot scanning or misbehaving clients can open large numbers of connections in a short time. TR7 limits the rate of new connections through maxConnRate and rateLimitSessions, protecting the backend from a connection storm.
Slow-reading clients can increase per-connection buffer usage. TR7 constrains the memory consumption of this traffic with a lower maxBufferSize profile, allowing other users to continue receiving service.
8-axis connection limit profiles for connection storms, TLS load and slow-client memory pressure. Let us walk through a live setup on your own services.