Breakpoint / capacity test

A breakpoint test (also called a capacity test) ramps load step by step until the system breaks: latency becomes unacceptable, errors rise, or the system fails outright. A stress test uses a smooth ramp. A breakpoint test uses separate, held stages, so the system settles at each level before the next step starts.

Before you start

• Your system passes a load test at expected peak.
• You have explicit authorisation to push the target to failure. Tell ops and stakeholders before you start.
• Run against an isolated staging environment, not production.

What is a breakpoint test?

A breakpoint test raises load in fixed stages, for example 100 VUs → 200 VUs → 400 VUs → 800 VUs. Each stage has a hold period (5–10 min) so the system can reach a new steady state. The test continues until:

1. Latency crosses your hard SLO threshold (e.g., p95 > 2 s), or
2. Error rate rises above your failure budget (e.g., > 2 %), or
3. The system becomes unreachable.

The VU count at the last stable stage is your capacity ceiling. The stage where failure begins is the breakpoint.

Capacity planning starts from these numbers. If your ceiling is 800 VUs and you expect peak demand of 600 VUs, you have a 33 % headroom margin. If the ceiling is 450 VUs against a 600 VU demand, you need to scale out before the next traffic event.

How to run a breakpoint test in MaxoPerf

Load profile

Parameter	Value
Stage steps	2× each step (100 → 200 → 400 → 800)
Hold per stage	5–10 min
Total duration	4–6 stages × hold time
Stop mode	Duration (or manual when failure observed)
Locations	Single location for isolation

Console walk-through

Use a Taurus YAML with explicit concurrency stages:

execution:
  - executor: jmeter
    concurrency:
      - const: 100
        duration: 8m
      - const: 200
        duration: 8m
      - const: 400
        duration: 8m
      - const: 800
        duration: 8m
    scenario: capacity-check

scenarios:
  capacity-check:
    requests:
      - url: https://api.staging.example.com/v1/products
        label: list-products
      - url: https://api.staging.example.com/v1/checkout
        label: checkout
        method: POST
        body: '{"cartId":"cart-{{__Random(1,1000)}}"}'

1. Upload the YAML and set Duration to cover all stages (32m for four 8-minute stages).
2. Set a Failure criteria, for example error rate > 5 %, so the run is marked failed automatically at the breakpoint. You then have a clean record of when the system hit the ceiling.
3. Start the run and watch the Overview tab live. The step pattern shows up in the throughput and latency charts.

How to read the result

Open the Overview tab:

• Throughput (RPS). It should rise at each stage. If throughput flattens or falls while VUs keep climbing, the system has hit a queue or resource ceiling.
• p95 latency. Look for the stage where p95 climbs sharply and does not recover during the hold. That is the breakpoint stage.
• Error rate. The stage where the error rate first goes above zero is usually the true breakpoint, even if latency is still acceptable.

Record the VU count of the last stable stage as your verified capacity ceiling. Share it with your infrastructure and product teams for capacity planning.

Do / don’t

Do	Don’t
Hold each stage long enough to reach steady state (≥ 5 min)	Ramp continuously and lose the ability to identify stable stages
Double VU count per stage for logarithmic coverage	Use very small steps (e.g., +10 VUs), which take too long
Set failure criteria to auto-record the breakpoint	Manually watch the run hoping to catch the exact failure moment
Document the ceiling VU count for capacity planning	Run a breakpoint test right before a production event
Run on an isolated environment	Run on a shared staging environment with other tests in progress

Where to go next

• Scalability test: check that scaling the infrastructure moves the ceiling up.
• Stress test: a faster, smooth-ramp version for a quick ceiling estimate.
• Foundations: How much load do you need?: size your ceiling target before the test.
• Cookbook: Staged ramp profile: a reusable multi-stage load profile recipe.