Launch spike and soak

Game launches are the highest-stakes performance events in software. The window between “game goes live” and “login servers fall over” can be under five minutes. This page shows how to plan and run the two tests that get a game ready to ship. The launch spike checks that your system absorbs the day-one storm. The overnight soak checks that it runs cleanly for the next 72 hours.

Before you start

• Your game server, matchmaking, and backend APIs have each passed their individual load tests.
• Run the full test suite (spike + soak) in the staging environment, not production.
• Alert ops and QA before running. A spike at launch-scale can cause elevated errors that show up in monitoring.
• Read Test types: Spike test and Test types: Soak / endurance test for the underlying test patterns.

Part 1: Launch-day login spike

What the launch spike tests

The first 10 minutes after a game goes live bring a login storm far denser than anything the service sees again at steady state. Every player who pre-registered or pre-loaded the client hits the login, authentication and matchmaking services at once. The spike test checks that:

• The authentication service handles the full registration queue without 5xx responses.
• Session allocation does not fail when match demand exceeds the pre-warmed server pool.
• Leaderboard and profile services handle the simultaneous write blast at first login.
• The system recovers and stabilizes after the initial surge, in addition to surviving it.

Load profile for a launch spike

Phase	VUs	Duration	Notes
Baseline	50	1 min	Warm state, no storm
Launch surge	5 000	3 min	Peak login density
Hold at peak	5 000	5 min	Sustained post-surge load
Ramp down	50	2 min	Back to steady state
Recovery observation	50	3 min	Watch for lingering errors

Total run time: ~14 minutes. Do not skip the recovery observation phase. A system that survives the surge but keeps showing errors after load drops has a resource-exhaustion problem (connection pool, thread pool, in-flight request queue). That problem will show up all through launch day.

Taurus configuration

execution:
  - executor: k6
    concurrency:
      - const: 50
        duration: 1m
      - const: 5000
        duration: 3m
      - const: 5000
        duration: 5m
      - const: 50
        duration: 2m
      - const: 50
        duration: 3m
    scenario: launch-login

scenarios:
  launch-login:
    script: launch-spike.js

launch-spike.js

import http from 'k6/http';
import { check, sleep } from 'k6';

export const options = {
  thresholds: {
    http_req_duration: ['p(95)<500'],    // auth + session under 500 ms at p95
    http_req_failed: ['rate<0.01'],      // < 1 % errors at peak
  },
};

export default function () {
  const headers = { 'Content-Type': 'application/json' };

  // Step 1: Authenticate
  const authRes = http.post(
    'https://auth.staging.example.com/v1/login',
    JSON.stringify({ username: `loadtest-user-${__VU}`, password: __ENV.TEST_PASSWORD }),
    { headers }
  );
  check(authRes, { 'login 200': (r) => r.status === 200 });
  if (authRes.status !== 200) return;

  const token = authRes.json('access_token');
  const authHeader = { headers: { Authorization: `Bearer ${token}`, ...headers } };

  // Step 2: Load player profile (every player on login)
  const profileRes = http.get('https://api.staging.example.com/v1/players/me', authHeader);
  check(profileRes, { 'profile 200': (r) => r.status === 200 });

  // Step 3: Enqueue for matchmaking
  const queueRes = http.post(
    'https://matchmaking.staging.example.com/v1/queue',
    JSON.stringify({ mode: 'casual' }),
    authHeader
  );
  check(queueRes, { 'queue 202': (r) => r.status === 202 });

  sleep(2);
}

import Screenshot from ‘@components/Screenshot.astro’;

Part 2: Overnight soak

What the overnight soak tests

The launch spike covers the day-one storm. The overnight soak covers the next 72 hours: it holds steady-state load for 8–12 hours to surface slow resource leaks, database connection exhaustion and gradual latency drift. For games, the soak also checks game-loop stability. The game server must not accumulate lag or drop events over long session windows.

Use the same VU count as your steady-state load test, not the spike peak. The soak measures continuous load over time, not maximum load.

Load profile for an overnight soak

Parameter	Value
VUs	Steady-state target (e.g. 1 000 concurrent players)
Ramp-up	5 min
Hold	8–12 h
Location	Same as production distribution
Stop mode	Duration

execution:
  - executor: k6
    concurrency: 1000
    ramp-up: 5m
    hold-for: 8h
    scenario: overnight-soak

scenarios:
  overnight-soak:
    script: game-server-load.js   # same as concurrent-player test

Set a Failure criteria on error rate (> 0.5 %) and p95 message latency (> 150 ms). MaxoPerf then fails the run automatically if a leak causes degradation mid-soak, and you do not need to watch the dashboard overnight.

Reading the soak result

After the soak completes, open the Overview tab and look for:

• Latency drift. p95 message latency should be flat across 8 hours. Investigate an upward drift of more than 20 %. It often points to a memory or connection pool leak.
• Throughput decline. Messages per second at constant VUs should be flat. A decline means the server processes each tick more slowly over time (garbage collection pauses, increasing lock contention, growing data structures).
• Error rate inflection. Errors that appear only after 4–6 hours are typical of resource exhaustion (open file descriptors, connection pool limits, session table overflow).

Compare MaxoPerf’s latency drift chart with your server’s heap metrics, open connection count and GC pause logs to find the root cause.

Cross-linking spike and soak

Run the launch spike first. If the spike passes all thresholds, run the overnight soak. If the soak shows drift after 4 hours, fix the leak and run the spike again to confirm the fix did not change launch-day behavior. Together, these two tests give you the full pre-launch performance sign-off.

Do / don’t

Do:

• Include a recovery observation window (3 min minimum) after the spike. The recovery curve matters as much as surviving the peak.
• Use the same test scenario for both spike and soak so you test the same code paths.
• Set failure criteria before the run. Nobody should be deciding by hand whether a 420 ms p95 is “acceptable” during a launch-night review.

Don’t:

• Skip the soak because the spike passed. They test different failure modes.
• Run the soak at spike-level VU count. That tests sustained stress instead of steady-state stability, and it exhausts resources that normal operation never would.
• Use production player accounts as test identities. Use dedicated loadtest accounts with the same permission set as real players.

Where to go next

• Test types: Spike test: the spike test pattern.
• Test types: Soak / endurance test: the soak test pattern.
• Daily scenarios: recurring event scenarios (patch day, raid boss, weekend soak).
• Matchmaking and lobby testing: add matchmaking to the launch-spike scenario.
• Cookbook: Scheduled runs: automate the overnight soak with MaxoPerf schedules.