OpenShift Route Capacity Calculator

Size the OpenShift ingress router: routes and connections per router pod, TLS handshake rate and connection-limit utilisation.

About OpenShift Route Capacity Calculator

Router load is about concurrency, not throughput: Little's law turns a request rate and a connection lifetime into the number of sockets HAProxy holds open, and that is what the maxconn limit governs. TLS is a second, independent constraint because only non-resumed handshakes cost an asymmetric crypto operation. Every route in the cluster shares the same router pods, so one team's traffic growth exhausts everyone's ingress — and above roughly a thousand routes the HAProxy configuration reload itself becomes the limiting factor.

Formula

OpenShift Route Capacity

concurrent connections = routes × requests per second × connection lifetime; per pod that is divided by the replica count and compared with ROUTER_MAX_CONNECTIONS.

connection lifetime: How long keep-alive holds a socket open, not the request duration
ROUTER_MAX_CONNECTIONS: HAProxy maxconn per router pod
full handshake: TLS negotiation that is not resumed, costing an RSA or ECDSA operation

Worked example

With the default values below, OpenShift Route Capacity Calculator returns Connections per Router Pod of 4,000. Change any input above and every figure here is recalculated in your browser.

Inputs used

Routes exposedaccepts 1–50,000 routes: 400 routes
Router pods (replicas)accepts 1–60 pods: 2 pods
Requests per second per routeaccepts 0.01–10,000 req/s: 5 req/s
Average connection lifetimeaccepts 0.1–600 seconds: 4 seconds
ROUTER_MAX_CONNECTIONS per podaccepts 100–2,000,000 connections: 20,000 connections
Routes terminating TLS at the routeraccepts 0–100 %: 80 %
TLS sessions resumedaccepts 0–100 %: 60 %

Results

Connections per Router Pod: 4,000 connections
Total Requests per Second: 2,000 req/s
Routes per Router Pod: 400 routes
Connection Limit Used: 20.0%
Full TLS Handshakes per Second: 320.0 handshakes/s
Router Sizing Verdict: Comfortably within router capacity

Step by step

1Values used
2OpenShift Route Capacity
3Connections per Router Pod= 4,000 connections
4Total Requests per Second= 2,000 req/s
5Routes per Router Pod= 400 routes
6Connection Limit Used= 20.0
7Full TLS Handshakes per Second= 320.0 handshakes/s
8Router Sizing Verdict= Comfortably within router capacity

Assumptions and limits

The result is derived only from the 7 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

How is OpenShift Route Capacity calculated?

concurrent connections = routes × requests per second × connection lifetime; per pod that is divided by the replica count and compared with ROUTER_MAX_CONNECTIONS. Router load is about concurrency, not throughput: Little's law turns a request rate and a connection lifetime into the number of sockets HAProxy holds open, and that is what the maxconn limit governs. TLS is a second, independent constraint because only non-resumed handshakes cost an asymmetric crypto operation.

Why does OpenShift Route Capacity matter?

Every route in the cluster shares the same router pods, so one team's traffic growth exhausts everyone's ingress — and above roughly a thousand routes the HAProxy configuration reload itself becomes the limiting factor.

What values do I need to enter?

This calculator takes 7 inputs: Routes exposed, Router pods (replicas), Requests per second per route, Average connection lifetime, ROUTER_MAX_CONNECTIONS per pod, Routes terminating TLS at the router, TLS sessions resumed. The pre-filled defaults are a realistic starting point — replace them with figures from your own environment for a result you can act on.

Why does route count matter separately from traffic?

Each route becomes HAProxy backend configuration, and a change to any route triggers a reload of the whole configuration. At high route counts those reloads get slow and overlap, which is why the router supports dynamic configuration for backend changes rather than a full reload.