Proxy Capacity Calculator
Calculate maximum concurrent connections and throughput for a proxy/reverse-proxy tier from worker count and per-worker connection limits.
Inputs
e.g. nginx worker_processes, HAProxy processes/threads
e.g. nginx worker_connections
Max Concurrent Connections
80,000
Theoretical Max Requests/sec
1,600,000req/s
Theoretical Max Throughput
819,200.0Mbps
Requests/sec per Connection
20.00
Step by step
Values used
Number of Worker Processes = 8; Max Connections per Worker = 10,000; Average Request/Response Size = 64 KB; Average Latency per Request = 50 ms
Max concurrent connections
max_conns = workers × conns_per_worker
Throughput
throughput = max_conns × (1000/latency_ms) × req_size_KB × 8 / 1000
Max Concurrent Connections
= 80,000
Theoretical Max Requests/sec
= 1,600,000 req/s
Theoretical Max Throughput
= 819,200.0 Mbps
Requests/sec per Connection
= 20.00
How it works
A proxy tier's connection ceiling is simply worker processes multiplied by each worker's configured connection limit. Converting that into a throughput estimate requires an additional assumption about request latency — since a connection handling short, fast requests can cycle through many more requests per second than one handling slow requests, effective request-per-second capacity depends on both connection count and how quickly each connection's request completes and frees up for the next one.
Formulas
Max concurrent connections
max_conns = workers × conns_per_worker
Throughput
throughput = max_conns × (1000/latency_ms) × req_size_KB × 8 / 1000
- C
- Max concurrent connections
- L
- Average latency in ms
- S
- Average request/response size in KB
Frequently Asked Questions
Why does connection count alone not determine throughput?
A connection serving many small, fast requests per second contributes far more request throughput than one holding open a slow, long-running request — throughput depends on both how many connections are open and how quickly each one's request completes, which is why latency is a required second input alongside raw connection capacity.
How do I increase proxy capacity without more hardware?
Increase worker process count (up to the number of available CPU cores, beyond which more workers don't help and can hurt due to context-switching overhead), raise the per-worker connection limit (bounded by available file descriptors and memory), or reduce backend latency so each connection frees up faster.
What limits per-worker connection count in practice?
Operating system file descriptor limits (each connection consumes at least one file descriptor) and available memory (each connection has a memory footprint for buffers) are the usual practical ceilings — raising worker_connections in configuration without also raising OS-level ulimits will not actually increase real capacity.