Capacity planning and traffic modeling

Before you can write a single line of test configuration, you need to know what number to test against. Traffic modeling translates the question “how bad could it get?” into a concrete virtual-user target that you configure in MaxoPerf. Without this step, you are guessing — and your stress test either runs at a number too low to find real problems, or too high to mean anything useful.

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

The key mistake teams make is setting VU counts based on intuition (“let’s do 1000 users”) rather than data. This produces one of two failure modes:

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

Grounding the test in real data eliminates both failure modes.

Step 1: Establish the historical baseline

Pull last year’s BFCM traffic data and find the peak concurrent sessions or peak RPS in a 5-minute window. If you do not have last year’s data (e.g., you are a new business), use the highest traffic day you have 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 a safety headroom of 20 % to account for 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 from analytics and virtual users in a load test are related but not identical. A virtual user in MaxoPerf makes one request, waits (think time), then makes another — similar to 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 the rule of thumb: VUs ≈ 10 % of peak concurrent sessions for a typical e-commerce browsing + checkout mix. In this example: 13,600 × 0.10 = 1,360 VUs — 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 using the throughput stop mode, or you can calculate the VU count that produces your target RPS at your expected average latency.

Step 3: Break down by funnel stage

Not all pages receive equal traffic. A checkout endpoint with 2 % conversion sees a fraction of the traffic that a homepage sees. 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 drives your end-to-end journey load test scenario weights. If your checkout scenario allocates 100 % of VUs to the payment endpoint, you are not modeling real traffic — you are stress-testing payment in isolation.

Step 4: Configure the target in MaxoPerf

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

Step 5: Document the model

Record the following so the whole team operates 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.

Tip

If you have a new product line launching on BFCM, model it separately. Traffic to new categories does not follow the same funnel ratio as established categories. Add a separate scenario in your test script to model the new-product traffic independently and merge VU counts at the top level.

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 — model error will 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 — adjust if actual throughput differs	Lock the numbers before your first run and never update them

Where to go next

• Realistic peak load profiles — translate these numbers into a staged test configuration.
• Foundations: How much load do you need? — the general theory behind VU count derivation.
• 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 from this page.