Estimate the concurrent connection capacity of an Ingress controller deployment.
An ingress controller's throughput ceiling is bounded by how many concurrent connections its workers can hold and how quickly each connection's request completes: max_rps = workers × connections_per_worker ÷ avg_latency_sec. Longer backend response times reduce achievable throughput proportionally, since each slow request occupies a connection slot for longer — this is essentially Little's Law applied to the ingress layer.
max_rps = connections × requests_per_connection / avg_latency_sec
By Little's Law, the number of requests a fixed pool of connections can serve per second is inversely proportional to how long each request occupies a connection — halving backend latency effectively doubles achievable throughput at the same concurrency level.
Increasing worker_processes generally scales better since it uses multiple CPU cores in parallel, while raising worker_connections on too few workers can hit single-core CPU bottlenecks well before the connection limit is reached.
This is a simplified capacity model; with HTTP keep-alive, a single connection serves many sequential requests, so actual sustainable RPS can exceed what this formula suggests if avg_latency is interpreted as full connection lifetime rather than per-request service time — use per-request latency for the most accurate estimate.
For simple reverse-proxying to fast backends, single-digit milliseconds is achievable; latency-bound backends (database-heavy APIs, external calls) can push average request latency into the tens or hundreds of milliseconds, directly capping ingress throughput.