Daily scenarios — game & network load testing recipes

This page is a practical reference for the recurring game performance scenarios that recur throughout a live game’s lifecycle. Each scenario states what you are testing, 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 simultaneously. Authentication, profile load, and matchmaking must absorb the concentrated 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 — time to fix issues found.

What to watch: Error rate during the ramp. 429 or 503 responses on the auth endpoint indicate 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, simultaneous increase 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, not a new workflow.
• Run 24 hours before the event goes live.
• Add failure criteria on game_msg_latency_ms p95 — the event experience is real-time.

What to watch: ws_connecting during the rapid ramp. Connection queuing on the game server appears as ws_connecting p95 climbing above 1 000 ms during the surge. If it climbs, the server’s connection-accept backlog needs tuning.

---

Scenario 3 — Matchmaking storm

What it tests. After a patch, server-restart, or event, all active players attempt to enter the matchmaking queue simultaneously. The matchmaking backend must handle the burst enqueue rate and form matches at normal quality (match time, balance) despite the sudden queue depth increase.

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. Any timeout means players abandoned in 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 validates that game servers and backend services maintain performance across an extended high-load period without 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 %. This lets MaxoPerf fail the run automatically if drift occurs mid-soak — no need 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. Any upward trend in p95 after hour 4 signals a slow leak (heap, connection pool, session table) that will manifest 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 simultaneously. This is effectively a secondary launch for the new region.

Load shape. Spike at the new-region opening time, then sustained load as the region stabilizes. 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

The weekend soak and nightly regression checks benefit from automation. Use MaxoPerf’s scheduled runs (available in Test detail → Schedules tab) to 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.