Load Balancer Capacity Calculator
Estimate whether a load balancer pool can handle peak requests, concurrent connections, new connections per second, and wire throughput. Enter workload demand, node ratings, target utilization, overhead, and failover reserve to find the bottleneck and the number of nodes needed.
Inputs
Results
Advertisement
How to use this load balancer capacity calculator
- Start with measured peak traffic: use observed busy-hour requests per second and connection rate when possible.
- Set connection behavior: short-lived HTTP connections drive new connection rate, while keep-alive and WebSocket traffic drive concurrent connections.
- Enter payload sizes: request and response payloads estimate payload throughput before protocol overhead.
- Model resilience: reserve nodes for failure, maintenance, or zone loss, then keep target utilization below the selected ceiling.
- Check the bottleneck: the highest required-node dimension is the first capacity limit to address.
Formula and assumptions
Active serving nodes: total nodes - reserved or failed nodes
Concurrent connections: new connections/sec x average connection duration
In-flight requests: requests/sec x average request time in seconds
Payload throughput: requests/sec x (request KiB + response KiB) x 1024 x 8
Wire throughput: payload throughput x (1 + protocol overhead)
Design demand: raw demand x (1 + design headroom)
Target cluster capacity: per-node rating x active nodes x target utilization
Required serving nodes: ceil(design demand x imbalance / (per-node rating x target utilization)) for each capacity dimension, then use the maximum.
Worst-node utilization includes the imbalance percentage. This models uneven distribution from hashing, persistence, uneven zones, or hot backends.
Example sizing scenarios
| Scenario | Capacity pressure | Planning note |
|---|---|---|
| API gateway | Requests per second and TLS handshakes | Use vendor ratings measured with similar TLS ciphers, WAF rules, logging, and header sizes. |
| Long-lived WebSocket or streaming clients | Concurrent connections and memory | Connection count may be the bottleneck even when request rate is low. |
| Static media edge | Throughput | Average response size can dominate node count before RPS limits are reached. |
| Short-lived mobile traffic | New connections per second | Connection churn can exhaust handshake capacity before steady-state connection count looks high. |
Requests, connections, and throughput are different limits
A load balancer can run out of capacity in several independent ways. Request processing limits are tied to HTTP parsing, policy evaluation, routing, logging, TLS termination, and response handling. Concurrent connection limits are tied to memory, socket tables, keep-alive behavior, idle timeouts, and long-lived protocols. New connection limits are tied to accept rates, SYN handling, TLS handshakes, and connection setup work.
Throughput is another limit. A workload with moderate request rate can still require many nodes if responses are large or if both request and response bodies traverse the balancer. This calculator separates payload throughput from protocol overhead, then applies design headroom and target utilization so the estimate reflects a production planning posture rather than a perfect-lab maximum.
For production planning, replace the default per-node values with capacity test results from your own load balancer model, configuration, TLS policy, WAF rules, logging pipeline, and observability stack. Vendor headline ratings may be measured under ideal packet sizes or feature sets that do not match your deployment.
Methodology
The calculator turns traffic assumptions into four design demand dimensions: requests per second, concurrent connections, new connections per second, and wire throughput. It compares each dimension with the active cluster capacity after reserved nodes are removed and target utilization is applied. The largest required-node count is reported as the bottleneck.
Last reviewed: June 2026. Calculations are deterministic arithmetic and run locally in your browser.
FAQs
What is a safe target utilization for load balancers?
Many teams plan around 60% to 80% of tested capacity, then tune based on burst behavior, deployment risk, autoscaling speed, and failover requirements.
Should I size for total nodes or active nodes?
Size demand against active serving nodes after reserved or failed nodes are removed. Total nodes should include the reserve needed for maintenance or failure.
Why include new connections per second?
Short-lived traffic, TLS handshakes, and client churn can overload connection setup paths even when concurrent connections look acceptable.
Does this model backend server capacity?
No. It sizes the load balancer layer only. Backend pools, databases, caches, DNS, and upstream network links need separate checks.
Is this calculator private?
Yes. Inputs are processed locally and are not submitted to a server.
Disclaimer
This is an infrastructure planning aid, not a vendor guarantee or safety certification. Validate production designs with load testing, vendor documentation, observability data, failure drills, and change-management requirements.