Server Module Load Testing for Games
A game server behaves completely differently under load than in development. At 10 connections everything flies. At 500 — first race conditions appear in the lobby-manager. At 2000 — Postgres connection pool runs out, and matchmaking starts returning 503 with 8-second delay. Load testing is not stress-test for stress's sake, but finding the specific degradation point and understanding what breaks first.
Typical bottlenecks in game server architecture
Matchmaking under load. Match-finding logic is often implemented as periodic database polling: every 500ms select players from queue, form room, update statuses. With 1000 simultaneous players in queue that's 1000 UPDATE-queries every half second plus SELECT with GROUP BY on ratings. Without index on (status, rating, created_at) query starts doing seq scan on 500k-row table — and response time grows non-linearly.
State synchronization. Server game loop (tick loop) must process incoming events from all clients and broadcast updates. At 30 Hz tick rate and 64 players per match that's 1920 incoming messages per second per instance. If processing is not parallel but through single queue, adding heavy game logic (raycast hit checks, pathfinding) causes tick to drop and clients get desync.
Session store. Redis usually handles game sessions — but only if keys are designed correctly. Storing entire 50 KB PlayerState object in one Redis key and updating it wholly every tick is a bad idea. With 500 active matches that's 500 × 64 × 30 = 960,000 writes per second at 50 KB each. Redis won't handle it. Correct approach: store only delta or break into small fields with separate expire.
How we conduct load testing
First step — define target metrics: how many concurrent connections, what p95 latency for critical operations (matchmaking, match start, sync), maximum acceptable RPS for REST API.
Second step — profile under load, not just measure throughput. Tools depend on stack:
- For Node.js servers: Artillery or k6 for load generation, clinic.js for flame graph CPU/memory
- For Python/Django: Locust with custom WebSocket-clients
- For Go: built-in profiler (pprof) + wrk/vegeta for HTTP, custom goroutine-bots for WS
- For Photon Server (self-hosted): built-in Dashboard + external bots on Photon Client SDK
To simulate real game traffic we write bot-clients — scripts that connect to server, authorize, perform typical game actions (movement, shooting, item pickup) in randomized pace. This matters more than just loading HTTP-endpoints because game sessions have specific traffic pattern: burst at match start, steady state during play, burst at end.
On one project — browser MMO strategy — we found server didn't crash from connection count but from specific action: "attack enemy city" triggered chain of 14 sequential DB-queries in transaction without savepoints. With 200 simultaneous attacks table battles locked for 3–4 seconds, cascading slowdown to all other operations. Solution: CQRS, offload attack result calculation to separate job-queue, async notification.
Load testing stages
First — baseline: measure metrics at zero load and at 10% of target online. This is reference point.
Then — ramp-up test: gradually increase load from 10% to 150% of target value in 10–15 minute steps. Fix where degradation starts.
Soak test: target load for 2–4 hours. Reveals memory leaks, connection accumulation, degradation from heap fragmentation.
Spike test: sudden load jump 3–5x above normal (simulates server announcement or viral growth). Tests autoscaling and behavior under overload.
After each test — analyze flame graph, query explain plans, Redis/Postgres metrics, and specific optimization recommendations.
| Scale | Estimated Timeline |
|---|---|
| Audit + baseline measurement | 3–5 days |
| Full load testing cycle | 2–3 weeks |
| Testing + optimization + re-run | 4–6 weeks |
Cost is calculated after analysis of server architecture and target load metrics.