Daily scenarios — game & network load testing recipes

This page is a reference for the game performance scenarios that come back again and again during a live game’s lifecycle. Each scenario states what you test, what the load profile looks like, and how to configure and run it in MaxoPerf.

Before you start

• The game server and matchmaking service have baseline load test results you can compare against.
• You have a MaxoPerf workspace with runner locations matching your game’s player regions.
• Each scenario below uses a k6 entrypoint or Taurus YAML. Adapt VU counts and durations to your game’s scale.

---

Scenario 1: Patch-day login storm

What it tests. A mandatory patch forces all players to update before they can log in. The moment the patch window closes, all players log in at once. Authentication, profile load and matchmaking must absorb that demand.

Load shape. Near-instant ramp to peak login concurrency (matching your DAU peak), 3-minute hold, 5-minute ramp-down with recovery observation.

How to run in MaxoPerf:

• Create a test named patch-day-login-storm.
• Use the launch-spike.js script from the Launch spike and soak page.
• Set VUs to your expected simultaneous login count (typically 5–20 % of DAU).
• Add runner locations matching your main player regions.
• Set failure criteria: p95 auth latency < 500 ms, error rate < 1 %.
• Run 48 hours before the actual patch release, so you have time to fix what you find.

What to watch: Error rate during the ramp. 429 or 503 responses on the auth endpoint mean the login service needs horizontal scaling or rate-limit tuning.

---

Scenario 2: Raid boss / live event spike

What it tests. A scheduled live in-game event (raid boss spawn, limited-time mode opening, seasonal sale) causes a sharp jump in active sessions. Players who were AFK or in the main menu all join the event at the announced time.

Load shape. From steady-state VU count, ramp sharply (30–60 s) to 2–3× steady state, hold for 10 minutes, ramp back to steady state.

How to run in MaxoPerf:

• Duplicate your steady-state game server load test and rename it raid-boss-spike.
• Modify the stages config to add a 30-second ramp to 2–3× normal VU count.
• Use the same game server WebSocket script. The spike measures session capacity, so you need no new workflow.
• Run 24 hours before the event goes live.
• Add failure criteria on game_msg_latency_ms p95 because the event experience is real-time.

What to watch: ws_connecting during the rapid ramp. When the game server queues connections, ws_connecting p95 climbs above 1 000 ms during the surge. If you see that, tune the server’s connection-accept backlog.

---

Scenario 3: Matchmaking storm

What it tests. After a patch, server-restart or event, all active players try to enter the matchmaking queue at once. The matchmaking backend must handle the burst enqueue rate and still form matches at normal quality (match time, balance) while the queue grows suddenly.

Load shape. Ramp to 5–10× normal matchmaking queue throughput in 30 seconds, hold for 5 minutes, observe queue drain over 2–3 minutes.

How to run in MaxoPerf:

• Use the matchmaking storm Taurus YAML from the Matchmaking and lobby testing page.
• Set concurrency to 5–10× your normal matchmaking request rate.
• Set ramp-up: 30s for the storm shape.
• Add custom thresholds: matchmaking_wait_ms p95 < 30 000 ms (30 s).
• Upload parties.json data entity to mix party and solo enqueues (realistic mix: 60 % solo, 40 % parties of 2–5).
• Run this test after every matchmaking service deployment.

What to watch: The match found within 60s check failure rate. Each timeout is a player left in the queue. Track this metric across releases as a regression signal.

---

Scenario 4: Weekend soak

What it tests. Weekend peak hours bring sustained high concurrency for 4–8 hours, longer than any weekday session window. The weekend soak checks that game servers and backend services hold their performance through a long high-load period, with no memory leaks, connection exhaustion or latency drift.

Load shape. Ramp to weekend-peak VU count (typically your Friday-evening observed concurrent player count), hold for 6–8 hours, ramp down.

How to run in MaxoPerf:

• Create a test named weekend-soak-8h.
• Use the game server WebSocket script with the stage profile set to hold-for: 8h.
• Set VUs to your observed Friday-evening peak concurrent player count.
• Configure a Failure criteria: p95 message latency > 150 ms, error rate > 0.5 %. MaxoPerf then fails the run automatically if drift occurs mid-soak, so nobody has to watch.
• Schedule the run via MaxoPerf’s scheduled-runs feature to fire automatically every Friday at 22:00.
• Review Saturday morning: check the Overview tab for latency drift in the final 2 hours.

What to watch: Latency drift in the second half of the run. An upward trend in p95 after hour 4 points to a slow leak (heap, connection pool, session table) that will show up every weekend.

---

Scenario 5: New-region launch

What it tests. Adding a new geographic region to a live game (e.g. opening South Asia servers for the first time) means a new player cohort hits the login, matchmaking and game server infrastructure at the same time. In practice this is a second launch for the new region.

Load shape. Spike at the new-region opening time, then sustained load as the region settles. Layer this on top of the existing-region baseline load to model the total system impact.

How to run in MaxoPerf:

• Create a test named new-region-sa-launch.
• In Locations, add ap-south-1 (or whichever MaxoPerf runner location is closest to the new player region).
• Set the new-region runner location to carry the new-region player VU count.
• Keep existing-region runner locations at their current VU count.
• Run the test to model the combined load: existing regions at steady state, new region at launch spike.

What to watch: Per-region latency in the Overview tab, filtered by location. The new-region p95 should be similar to or lower than existing regions. If it is higher, the new game server deployment has a configuration or capacity problem. Also watch the total system error rate: a new-region launch should not degrade existing players’ experience.

---

Scheduling recurring scenarios in MaxoPerf

Automate the weekend soak and the nightly regression checks. MaxoPerf’s scheduled runs (in Test detail → Schedules tab) trigger tests on a cron schedule. Example recurring schedule for a production game:

Test	Schedule	When
Smoke test (1 VU, 1 min)	Every night at 02:00	Validates basic server health
Steady-state load test	Every night at 03:00	Regression against baseline
Weekend soak (8 h)	Every Friday at 22:00	Sustained load validation
Pre-patch spike	Ad hoc, 48 h before each patch	Launch-day readiness
Post-deploy smoke	On every CI deploy trigger	Immediate regression check

Where to go next

• Launch spike and soak: full configuration detail for the two main pre-launch tests.
• Matchmaking and lobby testing: matchmaking storm script and thresholds.
• Game network do and don’t: quick reference before running any scenario.
• Cookbook: Scheduled runs: automate any scenario on a recurring schedule.
• Test types: Soak / endurance test: the soak test pattern in detail.