Test Types
What Is a Breakpoint Test?
A breakpoint test ramps load steadily upward until the system violates its targets or fails, in order to find the exact load at which capacity runs out.
Also known as: Capacity Test, Breakpoint Testing
One test, one number
A breakpoint test exists to produce a single figure: the maximum load the system sustains while still meeting its targets. Everything about the design serves that output — a long, smooth, uninterrupted climb, with no plateaus or spikes to muddy where the curve turns.
That number is what capacity planning consumes. “We handle 4,200 requests per second at a P95 under 500 ms” is an input to headroom calculations, scaling policies, and launch decisions in a way that “the test passed” never is.
Define failure before you start
The breakpoint is wherever you decide it is, so decide first. Ramping until the process crashes measures the crash point, which is rarely the useful number — most systems become unusable long before they die.
Write the threshold down as an explicit condition, then find the load where it is first breached.
- P95 response time exceeds the SLO — usually the most honest definition.
- Error rate rises above a threshold such as 1%.
- Throughput stops increasing even as virtual users keep rising — the saturation point.
Reading the result
Plot achieved throughput against active virtual users and look for the knee. Below it the line is straight and each added user produces proportionally more work. At the knee the line flattens: users keep arriving, throughput does not grow, and the extra demand converts into queueing and rising response time instead.
Report the load just before the knee, not at it. The knee is where the system is already saturated, and running production at saturation leaves no margin for the traffic you did not predict.