Skip to content
ENExplore Calculators

Ingress Controller Capacity Calculator

Estimate the concurrent connection capacity of an Ingress controller deployment.

About Ingress Controller Capacity Calculator

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)

Worked example

With the default values below, Ingress Controller Capacity Calculator returns Max Throughput of 81,920. Change any input above and every figure here is recalculated in your browser.

Inputs used

Worker Processesaccepts 1–1,024 workers
4 workers
Connections per Workeraccepts 1–1,000,000 connections
1,024 connections
Avg Request Latencyaccepts 0.1–1,000,000 ms
50 ms

Results

Max Throughput
81,920 requests/sec
Total Concurrent Connections
4,096 connections
Max RPS per Worker
20,480 requests/sec

Step by step

  1. 1Total concurrent connections: workers × connections/worker= 4,096 connections
  2. 2Max RPS: total connections ÷ avg latency (sec)= 81920 req/sec
  3. 3Max RPS per worker= 20480 req/sec/worker

Assumptions and limits

  • The result is derived only from the 3 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 whole numbers, 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 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.

Related Calculators

Ingress Controller Capacity Calculator | Calcrivo