HTTP/2 Load Test — Concurrency, Throughput and Where It Breaks
This generates concurrent HTTP traffic against an endpoint and reports what happened: requests completed per second, the latency distribution, error counts, and how those change as concurrency rises. It speaks both HTTP/1.1 and HTTP/2, which matters because the two behave very differently under concurrency.
Why run it
To find the limit deliberately rather than during an incident. Capacity is usually estimated from current traffic and a comfortable-sounding multiplier, and that estimate is regularly wrong by an order of magnitude in either direction. The latency distribution is the part worth studying: mean response time stays flat long after the tail has become terrible, and it is the tail that produces timeouts and complaints. A test that only reports averages will tell you everything is fine while a meaningful share of requests are failing.
Why automate it
Capacity is not a property you measure once. It moves with every deployment, dependency change and data growth, and it almost always moves downward. Running the same test on a schedule against a representative environment turns capacity into a tracked metric rather than a number from a document written eighteen months ago, and it catches the deploy that halved throughput at the point it happened — when the cause is still obvious — rather than at the traffic peak that eventually exposes it.
What it gives you
A measured limit instead of an assumed one, tracked as it changes. The concurrency level where the tail latency turns is the number that actually determines whether a traffic spike is absorbed or becomes an outage.