Capacity planning and traffic modeling

Before you write any test configuration, you need a number to test against. Traffic modeling turns “how bad could it get?” into a virtual-user target that you configure in MaxoPerf. Skip this step and you are guessing. Your stress test then runs either too low to find real problems or too high to mean anything.

Before you start

Access to last year’s web analytics (Google Analytics, Adobe, or equivalent) and/or server-side request logs.
A rough estimate of the conversion funnel: what percentage of visitors add to cart, proceed to checkout, and complete payment.
Your current SLO thresholds: what p95 latency and error rate are acceptable during peak load.

Why model first, test second

Teams often set VU counts by gut feel (“let’s do 1000 users”) instead of data. That leads to one of two failures:

Undertesting. The 1000-user test passes and you declare readiness. Real BFCM traffic is 5000 concurrent users, and the system falls over.
Overtesting. The 5000-user number you picked is 10× actual peak. The test breaks everything, you spend weeks fixing issues production would never see, and you run out of time for real readiness work.

Base the test on real data and you avoid both.

Step 1: Establish the historical baseline

Pull last year’s BFCM traffic data. Find the peak concurrent sessions or peak RPS in a 5-minute window. If you have no data from last year (for example, you are a new business), take your highest-traffic day on record and apply a growth multiplier.

Worked example

Suppose your analytics show:

Peak concurrent sessions last Black Friday: 8,400 sessions in a 5-minute window
Business expects 35 % YoY growth this year

Projected peak concurrent sessions: 8,400 × 1.35 = 11,340 sessions

Add 20 % safety headroom to cover measurement error and unexpected surges: 11,340 × 1.20 = ~13,600 sessions

This is your target peak concurrent load.

Step 2: Derive concurrency (virtual users) from sessions

Concurrent sessions in analytics and virtual users in a load test are related, but they are not the same thing. A virtual user in MaxoPerf makes one request, waits (think time), then makes another, much like a real browser session with pauses.

Use Little’s Law to derive VU count:

VUs = Throughput (RPS) × Average response time (s)

Or, working from sessions:

VUs ≈ Peak concurrent sessions × (avg request duration / avg session think time)

For a typical e-commerce site with 500 ms average server response time and 5 s of think time between clicks:

VUs ≈ 13,600 × (0.5 / 5) = 1,360 VUs

For a simpler model, use this rule of thumb for a typical e-commerce browsing + checkout mix: VUs ≈ 10 % of peak concurrent sessions. In this example, 13,600 × 0.10 = 1,360 VUs, which gives the same result.

Worked RPS derivation

If you prefer to model by RPS rather than VUs:

Peak sessions: 13,600
Each session generates ~2 page requests per minute on average
Peak RPS = 13,600 × 2 / 60 = ~453 RPS

In MaxoPerf you can target RPS directly with the throughput stop mode. You can also calculate the VU count that produces your target RPS at your expected average latency.

Step 3: Break down by funnel stage

Pages do not get equal traffic. A checkout endpoint with 2 % conversion sees a fraction of the homepage’s traffic. Build a per-endpoint profile:

Funnel stage	Relative traffic	Endpoint examples
Homepage / category browse	100 %	`GET /`, `GET /category/:id`
Product detail page (PDP)	60 %	`GET /product/:id`
Search	40 %	`GET /search?q=...`
Add to cart	15 %	`POST /cart/items`
Checkout start	8 %	`GET /checkout`
Payment	2 %	`POST /checkout/payment`

This breakdown sets the scenario weights in your end-to-end journey load test. If your checkout scenario sends 100 % of VUs to the payment endpoint, you are stress-testing payment in isolation, not modeling real traffic.

Step 4: Configure the target in MaxoPerf

Open the MaxoPerf console and navigate to Tests → New test.
In the Load profile section, set Virtual users to your modeled peak VU count. In this example, that is 1,360.
Set Ramp-up to 5–10 minutes. Even a doorbuster spike has a brief ramp, so do not start at full VUs.
Set Duration to match your test type: 15–20 min for a load test, 30–60 min for a stress test.
In the scenario file, weight requests according to the funnel breakdown from Step 3.

Step 5: Document the model

Record these values so the whole team works from the same numbers:

Parameter	Value	Source
Historical peak concurrent sessions	8,400	GA4 (Black Friday 2024, 22:00–22:05 UTC)
YoY growth factor	1.35	Business forecast Q4 2025
Safety headroom	1.20	Engineering judgment
Target peak VUs	1,360	Modeled (Little’s Law)
Target peak RPS	~453 RPS	Sessions × request rate
Acceptable p95 latency	800 ms	SLO: checkout page
Acceptable error rate	0.5 %	SLO: payment endpoint

Store this document in your team wiki and link it from the MaxoPerf test description. When someone asks “why 1,360 VUs?”, the answer is one link away.

Do / don’t

Do	Don’t
Model from last year’s actual peak, not average traffic	Use your average daily traffic as the BFCM target
Add 20 % safety headroom above the modeled peak	Test at exactly the projected number and let model error bite you
Break down VU targets by funnel stage	Run all VUs against the checkout endpoint only
Document the model so the whole team uses the same numbers	Keep the VU number in your head and change it between tests
Revisit the model after each test run and adjust it if actual throughput differs	Lock the numbers before your first run and never update them

Where to go next

Realistic peak load profiles: turn these numbers into a staged test configuration.
Foundations: How much load do you need?: the general theory behind deriving a VU count.
Staged ramp profile: build the multi-stage YAML that matches your traffic model.
End-to-end journey load: weight your scenario steps by the funnel breakdown on this page.