Designing realistic load

A load test is only as useful as its realism. A profile that does not match your production traffic pattern will give you results that are either falsely reassuring or falsely alarming. This page shows you how to design load profiles that reflect the way real users actually interact with your system — and what to avoid.

Before you start

Understand the difference between open and closed workload models before choosing your VU or RPS target.
Decide whether you are controlling virtual users (VUs) or requests per second (RPS). See the ramp-up, think time, and pacing Foundations page.
Have at least one production traffic sample (APM trace, access log, or analytics export) to reference.

What makes a load profile realistic?

A realistic load profile has four ingredients:

Arrival rate / concurrency target — matches your expected peak or a defined multiple of it.
Ramp shape — mirrors how traffic actually builds (gradual ramp, sudden spike, step-wise).
Scenario mix — reflects the proportion of read vs write vs search vs checkout flows.
Think time and pacing — accounts for the time real users spend between requests.

Skipping any of these turns your “load test” into a synthetic hammer that tells you nothing about how your system behaves under real conditions.

Dos

Do derive your VU/RPS target from real traffic data. Pull peak RPS from your APM or access logs. If you have no baseline, start with a conservative estimate and run a smoke test first to confirm the setup is correct.
Do model scenario mix. If 70 % of your traffic is read-only (product pages, search) and 30 % is write-heavy (checkout, form submission), reflect that split in your test. In Taurus, use multiple scenarios: blocks with weighted concurrency:
```
execution:
  - concurrency: 70
    scenario: browse
  - concurrency: 30
    scenario: checkout
```
Do use a think time that matches human pacing. Add think-time: 1s or use a uniform distribution (uniform(0.5s, 2s)) in Taurus scenarios. Zero think time creates an artificially high per-VU request rate and saturates your server faster than real users would.
Do ramp gradually. A sudden jump from 0 to peak VUs hides warm-up behaviour and caching effects. A ramp-up: 3m gives your server (and its JIT/caches) time to settle before you read steady-state results.
Do use multiple MaxoPerf locations when your users are geographically distributed. Configure additional locations in the test’s Configuration tab. Per-location latency in the run Runners tab lets you spot regional differences.
Do test at the load level your failure criteria enforce. If your SLO says p95 < 500 ms at 500 RPS, your test must reach 500 RPS. Configure your failure criteria at that level.

Don’ts

Don’t use a flat, constant VU count as your only profile. Most real systems experience morning ramps, lunch peaks, and late-night troughs. A flat test misses the ramp behaviour entirely. Combine it with a staged ramp profile.
Don’t ignore think time on write-heavy flows. Write operations (POST, PUT, DELETE) are almost never issued back-to-back in production. Without think time between writes, your test will hit your database far harder than real usage.
Don’t test a single endpoint in isolation when your system is request-chain dependent. If your checkout flow triggers downstream calls (inventory, payment, email), a single-endpoint test will miss the cascade failures that only appear under combined load.
Don’t hardcode a single request body for all VUs. Identical payloads bypass caches and hit the same database rows every time, creating contention that does not exist in production. Use a CSV data entity to inject realistic variety.
Don’t set your target to “as many requests as possible” (max throughput mode) for a standard load test. This is a stress or breakpoint test, not a load test. Know which test type you are running — see Common pitfalls and anti-patterns.
Don’t size your runner count based on VUs alone. Each MaxoPerf runner has a maximum healthy VU capacity. If you push too many VUs onto too few runners, the runners become the bottleneck and your results reflect runner saturation, not your system under test. Check the Runners tab during the run.

Scenario mix reference

Traffic type	Taurus pattern	Typical weight
Read (GET, search, browse)	`requests: [GET ...]`	60–80 %
Authenticated read (session-gated)	`requests: [GET ...]` with extracted auth token	15–30 %
Write (POST/PUT checkout, form)	`requests: [POST ...]`	5–20 %
Heavy write (file upload, batch)	`requests: [POST ...]` with CSV data	1–10 %

Where to go next

Test data dos and don’ts — inject variety to avoid cache skew
Ramp-up, think time, and pacing — Foundations deep dive
Staged ramp profile recipe — step-by-step MaxoPerf walkthrough
Multi-region distributed load — configure multiple locations