Ingress Controller Capacity Calculator

Calculate the maximum request rate a Kubernetes ingress controller can serve given worker count, connections per worker and average latency.

Inputs

Worker Processesworkers

Number of worker processes/threads the ingress controller runs (e.g. NGINX worker_processes).

Connections per Workerconnections

Max concurrent connections one worker can hold open (e.g. NGINX worker_connections).

Avg Request Latencyms

Average time a connection is occupied handling one request (backend response time + processing).

Max Throughput

81,920requests/sec

Total Concurrent Connections

4,096connections

Max RPS per Worker

20,480requests/sec

Step by step

Total concurrent connections: workers × connections/worker
4 × 1024
= 4,096 connections
Max RPS: total connections ÷ avg latency (sec)
4,096 ÷ 0.0500s
= 81920 req/sec
Max RPS per worker
81920 ÷ 4
= 20480 req/sec/worker

How it works

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.

Formula

max_rps = connections × requests_per_connection / avg_latency_sec

connections: Max concurrent connections supported
requests_per_connection: Requests per keep-alive connection
avg_latency_sec: Average backend response time (seconds)

Frequently Asked Questions

Why does average latency have such a big impact on max throughput?

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.

Should I increase worker_connections or worker_processes to scale?

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.

Does this model account for keep-alive connections?

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.

What's a typical avg_latency for a well-tuned ingress?

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.

You might also need

API Gateway Throughput Calculator Envoy Proxy Capacity Calculator Rate Limit Calculator