What is Breakpoint Testing?

What is breakpoint testing?

Breakpoint testing is a performance test that keeps raising load on a system, in controlled steps, until it fails, so you learn where its limit is. The result is a number you can plan around: the load at which response time, error rate or throughput crosses the line you defined as failure. It is also called capacity, point load or limit testing. (For CSS responsive-design breakpoints, see mobile-first design.)

How a breakpoint test works

1. Define failure first. For example p95 response time above a set value, error rate above a set percentage, or throughput that stops growing. Without this, you cannot tell when you have found the limit.
2. Ramp up gradually. Sudden jumps make it hard to tell when and why the system failed.
3. Keep going through degradation. Unlike most test types, a breakpoint test does not stop when the system gets slow. It stops when your failure condition is met.
4. Stop on a threshold or by hand. In k6, a threshold with abortOnFail can end the run automatically.
5. Find what saturated. CPU, memory, a database connection pool or a thread pool: that is what to scale or fix.

Example

Illustrative numbers, not a benchmark. An API holds a steady p95 at 100 virtual users. You add 50 users every minute. Around 400 users p95 starts to climb faster than the load, and at 550 users the error rate passes 1%. The breakpoint is about 550 users, and the knee near 400 is the more conservative planning number. Fix the bottleneck, run the same ramp again, and see whether both numbers moved.

Breakpoint vs stress, capacity and spike testing

• Capacity testing looks for the highest load that still meets your targets. Breakpoint testing looks for where it stops meeting them. Some sources use the two terms for the same thing.
• A stress test pushes beyond expected peak to see how the system fails and recovers. A breakpoint test measures where it fails. See load testing vs stress testing.
• Spike testing applies a sudden jump. A breakpoint test climbs steadily. Both build on load testing.

Common mistakes

• Leaving autoscaling on. Grafana's k6 guide warns that elastic environments may keep growing until you hit your account's spending limit. Turn elasticity off for the components under test, or you measure your budget.
• Ramping too fast, which hides where the knee is.
• No failure definition, so the run just ends when someone gets bored.
• A saturated load generator. If the machine producing load runs out of CPU first, you measure the generator, not the system.
• Testing a system you do not own or have permission to test. A breakpoint test is meant to break things: use a staging copy or agreed window, never a shared or production system without sign-off.
• Running it once. Repeat after each tuning change to see whether the limit moved.

Running breakpoint tests with LoadFocus

In JMeter, the Stepping Thread Group plugin adds users in portions at a fixed interval. In k6, a ramping scenario with several stages does the same. LoadFocus runs existing JMeter scripts and k6 JavaScript scripts from up to 25 cloud regions, and on paid plans up to 20,000 concurrent virtual users per test (the free plan is limited to 10, so a real ceiling search needs a paid plan). You can set maximum P95 and P99 response time, maximum error rate and minimum throughput as thresholds, and the results chart errors and response codes against the number of virtual users, which is the curve you read the breakpoint from. Start at LoadFocus load testing. For the ramp itself, see the JMeter ramp-up period.

FAQ: breakpoint testing

Is breakpoint testing the same as stress testing?

They overlap. Stress testing asks how the system behaves and recovers beyond its limits. Breakpoint testing asks where exactly the limit is.

How do I know when to stop the test?

When your predefined failure condition is met, such as p95 above a limit or error rate above a percentage. In k6 a threshold with abortOnFail can stop the run for you.

Should I run it in production?

Not unless you have explicit approval and a plan. The test is designed to cause failure, so a staging copy of production is the safer place.

How often should I repeat it?

After major code or infrastructure changes, when load is growing, and after tuning, to see whether the limit moved.