Estimate the number of concurrent connections a proxy server can handle.
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.
Max concurrent connections
max_conns = workers × conns_per_worker
Throughput
throughput = max_conns × (1000/latency_ms) × req_size_KB × 8 / 1000
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.
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.
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.