Ingress Capacity Calculator
Calculate the request throughput an Ingress controller can sustain under load.
About Ingress Capacity Calculator
An Ingress controller's throughput ceiling is bounded by how many concurrent connections it can hold open and how quickly each connection cycles through requests, which is the inverse of average request latency. This calculator models max RPS as concurrent connections divided by average latency per request — the same connection can serve many sequential requests per second if latency is low, so lowering backend latency raises ingress throughput just as much as adding connection capacity.
Formula
maxRPS = connections × (1 / avgLatency)
- C
- Concurrent connections supported
- L
- Average request latency in seconds
- R_{max}
- Maximum requests per second
Worked example
With the default values below, Ingress Capacity Calculator returns Max Ingress Throughput of 40,000. Change any input above and every figure here is recalculated in your browser.
Inputs used
- Concurrent Connectionsaccepts 1–10,000,000 connections
- 2,000 connections
- Requests per Connectionaccepts 0.1–100,000 req/conn
- 10 req/conn
- Average Request Latencyaccepts 0.001–60 seconds
- 0.05 seconds
Results
- Max Ingress Throughput
- 40,000 req/s
- Requests/sec per Connection
- 20.0 req/s
Step by step
- 1Requests per second per connection = 1 ÷ latency= 20.0 req/s
- 2Max RPS = connections × req/s per connection= 40000 req/s
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 1 decimal place, 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
What limits concurrent connections on an Ingress controller?
Worker process count and worker_connections settings (for NGINX-based controllers), file descriptor limits on the pod, and the controller's own resource requests/limits — scaling the Ingress controller's replicas and per-pod connection limits raises this ceiling.
Why does backend latency affect ingress throughput so much?
Each connection can only serve one request at a time; higher backend latency means each connection completes fewer requests per second, directly capping total throughput even if raw connection count is high.
Should I scale the Ingress controller or the backend first?
Profile first — if backend latency is the bottleneck, scaling the Ingress controller alone won't help; if the Ingress controller pods are CPU/connection-saturated while backends have spare capacity, scale the controller.