Load test

A load test validates that your system performs acceptably under the traffic levels you actually expect. It answers the 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 applies a sustained, realistic number of virtual users for long enough to reveal how the system behaves at steady-state. Unlike a stress test (which pushes beyond limits), a load test stays within expected operating range.

A well-designed load test has three phases:

1. Ramp-up — gradually increase VUs to target level (avoids cold-start noise).
2. Hold / plateau — sustain target VU count long enough for the system to reach steady state (≥ 10 min for most systems).
3. Ramp-down (optional) — gradually decrease VUs; useful for watching 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 automatically marks as failed if the threshold is breached. See Failure criteria.

6. Click Run and monitor the live results.

How to read the result

Once the run reaches finished, open the Overview tab:

• Throughput (RPS) — confirm it stabilises on the plateau. A climbing or crashing throughput line means the system is not at steady state.
• p95 latency — this is your headline metric. Does it stay below your SLO threshold through the whole hold phase?
• Error rate — should be near zero. Any errors during the plateau are a problem.
• Runners tab — verify all runners were healthy; a saturated runner skews latency readings.

Tag the run as baseline if it is the first successful run at this profile. Later load tests can be compared 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 — it 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 cause disruption if the system is under-provisioned or shared with other teams. Prefer staging over production for initial 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 — understand RPS, error rate, and percentiles.
• Cookbook: Staged ramp profile — build a multi-stage ramp for more realistic traffic shaping.