Load test

A load test checks that your system performs acceptably at the traffic you actually expect. It answers one question: “Does the system meet its SLOs when a realistic number of users are active at the same time?”

Before you start

• A smoke test has passed against the same target.
• You have an estimate of your peak concurrent users or target RPS. See How much load do you need?.
• Your target environment is sized to handle real traffic (staging or production).

What is a load test?

A load test holds a realistic number of virtual users long enough to show how the system behaves at steady state. A stress test pushes past the limits. A load test stays inside the expected operating range.

A good load test has three phases:

1. Ramp-up. Raise VUs gradually to the target level, which avoids cold-start noise.
2. Hold / plateau. Keep the target VU count long enough for the system to reach steady state (≥ 10 min for most systems).
3. Ramp-down (optional). Lower VUs gradually. This lets you watch drain behaviour.

How to run a load test in MaxoPerf

Load profile

Parameter	Value
Virtual users (VUs)	50–500 (match your expected peak concurrency)
Ramp-up	2–5 min to target VU count
Hold duration	10–30 min at plateau
Stop mode	Duration
Locations	1–3 managed cloud regions

Console walk-through

1. From your project, click New test (or open an existing one and click Edit).

2. Upload your test script. A typical Taurus YAML for a load test:

   execution:
     - executor: jmeter
       concurrency: 100
       ramp-up: 3m
       hold-for: 15m
       scenario: api-load
   
   scenarios:
     api-load:
       requests:
         - url: https://api.staging.example.com/v1/products
           label: list-products
         - url: https://api.staging.example.com/v1/cart
           label: get-cart
           method: POST
           body: '{"userId":"user-42"}'

3. In Load profile, set Virtual users to your target concurrency (e.g., 100), Ramp-up to 3m, and Duration to 15m.

4. Select 1–3 managed locations. For a distributed load test, see Multi-region distributed load.

5. Optionally, set Failure criteria (for example, p95 < 500 ms) so the run is marked failed automatically if it breaches the threshold. See Failure criteria.

6. Click Run and watch the live results.

How to read the result

Once the run reaches finished, open the Overview tab:

• Throughput (RPS). Confirm it levels off on the plateau. A climbing or crashing throughput line means the system is not at steady state.
• p95 latency. This is your headline metric. It should stay below your SLO threshold for the whole hold phase.
• Error rate. It should be near zero. Any errors during the plateau are a problem.
• Runners tab. Check that all runners were healthy. A saturated runner skews latency readings.

If this is the first successful run at this profile, tag it baseline. You can compare later load tests against it.

Do / don’t

Do	Don’t
Use a ramp-up to avoid cold-start noise	Start at full VU count with no ramp, which can spike error rates
Run long enough to see steady-state (≥ 10 min hold)	Stop after 2 min and declare the test done
Base VU count on real traffic data or estimation	Guess a “big” number that your system cannot handle
Set failure criteria so CI gates automatically	Manually inspect every run without a pass/fail threshold
Compare to a known baseline run	Draw conclusions from a single run

Caution

Only run load tests against systems you own or have explicit authorisation to test. Even expected-peak load can disrupt a system that is under-provisioned or shared with other teams. Use staging rather than production for the first runs.

Where to go next

• Stress test: push beyond the load-test VU count to find the breaking point.
• Baseline regression test: turn this run into a CI gate.
• Foundations: Core metrics explained: RPS, error rate and percentiles.
• Cookbook: Staged ramp profile: build a multi-stage ramp for more realistic traffic shapes.