Skip to content
MaxoPerf MaxoPerf docs

How much load do you need?

“How many virtual users should I use?” is one of the first questions every new performance tester asks. The answer is not arbitrary — it comes from your traffic data. This page walks through the sizing math from real-world numbers to a MaxoPerf configuration.

Start with real traffic data

Section titled “Start with real traffic data”

Before you can size a test, you need to know what your system currently handles. Pull at least 30 days of traffic data from your analytics or observability platform:

  • Peak concurrent users: the maximum number of sessions active simultaneously (not daily visits).
  • Peak RPS: the highest request rate observed at the application server level.
  • Session duration: average time a user spends in the application before leaving.
  • Requests per session: average number of requests a user makes in one session.

If you have none of this, estimate conservatively: start small (10–20 VUs), observe the system behavior, and scale up. A smoke test first always.

Formula: concurrent users to VU count

Section titled “Formula: concurrent users to VU count”

The simplest sizing formula estimates peak concurrency from daily active users:

peak concurrent VUs ≈ (daily_active_users × avg_session_duration_seconds) / seconds_in_day × peak_multiplier

Example:

  • Daily active users: 50 000
  • Average session duration: 4 minutes (240 seconds)
  • Seconds in a day: 86 400
  • Peak multiplier: 4× (traffic spikes to 4× average at peak hours)
avg concurrent = (50 000 × 240) / 86 400 = ~139 concurrent users
peak concurrent = 139 × 4 = ~556 VUs

Round to a clean number: target 600 VUs for the peak load test, and use 150 VUs for the baseline load test.

Formula: RPS to VU count

Section titled “Formula: RPS to VU count”

If you have peak RPS from your metrics, you can work backwards:

VU count ≈ target_RPS × (avg_response_time_seconds + think_time_seconds)

Example:

  • Target RPS: 300
  • Average response time: 200 ms (0.2 s)
  • Think time: 2 s
VU count = 300 × (0.2 + 2.0) = 660 VUs

You need ~660 VUs with 2 s think time to sustain 300 RPS in a closed workload model.

If you omit think time (API clients with no human delay):

VU count = 300 × 0.2 = 60 VUs

At 60 VUs with no think time, each VU fires as fast as the server responds — 300 RPS if latency stays at 200 ms.

Formula: requests per session

Section titled “Formula: requests per session”

When you know requests-per-session and session duration, you can derive think time and then VU count:

avg_think_time = session_duration / requests_per_session - avg_response_time

Example:

  • Session duration: 5 minutes (300 s)
  • Requests per session: 30
  • Average response time: 200 ms
avg_think_time = 300 / 30 - 0.2 = 10 - 0.2 = 9.8 s

Each VU should wait ~9.8 s between requests. Now apply the RPS formula with this think time to get VU count for a target throughput.

Sizing for non-production environments

Section titled “Sizing for non-production environments”

Production-matching load is rarely achievable in staging. Staging databases are smaller, caches are colder, and fewer machines are available. A practical approach:

  1. Run at 20–30% of the production peak VU count in staging.
  2. Look for linear scaling behavior (throughput and latency move predictably with VU count).
  3. Extrapolate: if the system shows linear behavior at 100 VUs, predict behavior at 500 VUs.
  4. Flag any non-linear behavior (latency climbs disproportionately at higher VU counts) as a risk.

See Choosing safe test environments for more on staging vs production.

What to do when you have no traffic data

Section titled “What to do when you have no traffic data”

For a new system with no traffic history, use capacity targets from product or business requirements:

“The system must support 1 000 concurrent users at launch.”

Translate this to a load test configuration:

  • VU count: 1 000 (if no think time; otherwise apply the formula above).
  • Duration: 15 minutes hold after a 5-minute ramp.
  • Add 20% headroom: also test at 1 200 VUs to confirm the system degrades gracefully beyond the target.

Headroom and safety margin

Section titled “Headroom and safety margin”

Always test beyond your target load. A system that barely passes at the target load has no safety margin for traffic spikes, misbehaving clients, or unexpected data growth. A rule of thumb:

  • 1.5× target VU count: the system should still be functional (some latency increase acceptable).
  • 2× target VU count: the system should degrade gracefully — not return 500s or crash.

This is the basis of a stress test — deliberately pushing beyond the target to find the breaking point.

Do / don’t

Section titled “Do / don’t”
DoDon’t
Derive VU count from real traffic data — analytics, APM, or server access logs.Pick a round number (“let’s try 100 VUs”) without connecting it to real traffic.
Include think time in the sizing formula if you are modeling human users.Forget think time and then wonder why 50 VUs produce more RPS than expected.
Add a 1.5–2× headroom test above the target VU count.Test only at the exact target load — you will have no idea how close to the edge you are.
Document the sizing math in the test notes so the next engineer understands the load profile.Leave future teammates guessing why the test uses 847 VUs.

Where to go next

Section titled “Where to go next”