Calculate the request throughput an Ingress controller can sustain under load.
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.
maxRPS = connections × (1 / avgLatency)
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.
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.
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.