Proxy Capacity
Estimate the number of concurrent connections a proxy server can handle.
About Proxy Capacity
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
Worked example
With the default values below, Proxy Capacity returns Max Concurrent Connections of 80,000. Change any input above and every figure here is recalculated in your browser.
Inputs used
- Number of Worker Processesminimum 1
- 8
- Max Connections per Workerminimum 1
- 10,000
- Average Request/Response Sizeminimum 0.01 KB
- 64 KB
- Average Latency per Requestminimum 0.1 ms
- 50 ms
Results
- 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
Step by step
- 1Values used
- 2Max concurrent connections
- 3Throughput
- 4Max Concurrent Connections= 80,000
- 5Theoretical Max Requests/sec= 1,600,000 req/s
- 6Theoretical Max Throughput= 819,200.0 Mbps
- 7Requests/sec per Connection= 20.00
Assumptions and limits
- The result is derived only from the 4 inputs listed above. Anything not among them is not part of the calculation.
- In particular, this calculator does not take inflation, tax, fees or charges or compounding frequency into account.
- Figures are rounded for display to 2 decimal places, so totals built from several rounded parts can differ slightly from the unrounded arithmetic.
How these calculators are built and tested is described on the Methodology page. If a figure looks wrong, please report it.
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.