Skip to content
MaxoPerf MaxoPerf docs

Game & network load testing — do and don't

This page lists the most common mistakes in game and network load testing and the correct approach for each. Use it as a pre-run checklist before any game performance test in MaxoPerf.

Connection and session management

Section titled “Connection and session management”

Do: hold WebSocket connections open for a realistic session duration. Game player sessions last 2–30 minutes, not 10 seconds. Use socket.setTimeout() inside the k6 WebSocket handler to hold each virtual user’s connection for the target session duration (e.g. 5 min). Short connect/disconnect cycles test connection setup throughput instead of steady-state player load, and they will not reveal memory leaks or tick-rate degradation.

Don’t: treat a successful WebSocket handshake as a passed game server test. ws_connecting p95 measures TCP handshake time. It does not measure game-loop latency, message processing throughput or session stability under sustained load. Add custom Trend metrics for message RTT and use them as the primary pass/fail signal.

Metrics and thresholds

Section titled “Metrics and thresholds”

Do: set explicit failure criteria before running. Define p(95) and avg thresholds for ws_connecting, game_msg_latency_ms, and error rate in the k6 options.thresholds block. MaxoPerf fails the run automatically if any threshold is violated. Nobody should be deciding “is 420 ms acceptable?” by hand at midnight before a launch.

Don’t: use mean (average) latency as the headline game quality metric. Means hide the tail that players feel as lag spikes. A 30 ms mean RTT with a p99 of 800 ms is a badly performing server. Report p95 and p99 next to the mean, and set thresholds on both.

Load shape

Section titled “Load shape”

Do: ramp the spike within 30 seconds to simulate a launch storm or event spike. Real game launch traffic arrives in under a minute: thousands of players click “Play” at the moment the game goes live. A 10-minute ramp-up hides the launch-day failure mode. For launch simulation, use ramp-up: 30s in the Taurus YAML stages config.

Don’t: run only a spike without a recovery observation window. The recovery window (2–3 minutes after the VU count drops back to baseline) shows whether the system recovers or keeps showing elevated errors from resource exhaustion. A system that “survived” the spike but kept returning 5xx responses for 20 minutes afterward has not passed the launch-readiness test.

Geographic realism

Section titled “Geographic realism”

Do: use multiple MaxoPerf runner locations matching your real player distribution. Game players connect from everywhere. A single-region load test from the data center nearest your server gives best-case latency that no real player will see. Add at least one geographically distant runner location (e.g. EU runners for a US server) to expose the regional latency gap.

Don’t: infer UDP game server capacity from a WebSocket load test alone. WebSocket runs on TCP. UDP game servers behave differently under congestion, reordering and loss. Use WebSocket tests for services that use WebSocket. For UDP-based game protocols, test the control plane in MaxoPerf and validate the data plane separately with a UDP-capable tool.

Data and authentication

Section titled “Data and authentication”

Do: use unique player identities (player IDs, tokens) per virtual user. Most game services (matchmaking, leaderboards, inventory) deduplicate by player ID. If all 1 000 virtual users share one token, the server sees 1 000 requests from a single player. That triggers rate-limiting and deduplication paths that a real launch would not hit. Use a CSV data entity with one token per row, cycling with __VU % tokens.length.

Don’t: use production player accounts as load-test identities. Load tests write data: scores, session records, inventory mutations, matchmaking tickets. A 5 000-VU test with real player tokens pollutes real player data, sends notifications, changes leaderboard rankings and can trigger anti-cheat detection. Provision dedicated loadtest accounts with the same permission set as real players.

Matchmaking and lobby

Section titled “Matchmaking and lobby”

Do: include party (group) tokens in matchmaking test data. Solo matchmaking tests miss the combinatorial overhead of group matchmaking. A realistic test mixes solo and party enqueues (roughly 60 %/40 % for most titles). Pre-generate party tokens server-side and upload them as a MaxoPerf data entity.

Don’t: skip the session-join step in a matchmaking test. Issuing a queue ticket and measuring queue wait time covers only half the funnel. If the match forms but the session-join fails (e.g. the session server is overloaded), players still cannot play. Run the full enqueue → match → join sequence in the test.

Soak tests

Section titled “Soak tests”

Do: run the overnight soak at steady-state VU count, not spike VU count. A soak test at spike levels is a stress test, not a stability test. Use the same VU count as your regular load test. You are testing duration effects (leaks, drift), not maximum capacity.

Don’t: declare the soak passed just because no errors occurred. A soak that finishes with zero errors but shows a 30 % drift in p95 latency over 8 hours is a failing soak. The server is degrading and has not failed yet. Check the Overview tab for latency drift as well as the final error count.

Network conditions

Section titled “Network conditions”

Do: run at least one degraded-network variant (mobile, high-latency) per pre-release cycle. Real players do not have fiber connections to your data center. A test that passes from a co-located runner but fails for players in remote regions or on mobile networks is not ready for launch. See Network emulation conditions.

Don’t: accept a clean data-center-to-data-center result as representative of global player experience. Your players do not see the latency numbers your co-located test reports. Compare per-region latency from distant runner locations before you approve a pre-launch performance result.

Where to go next

Section titled “Where to go next”