Load Testing
Load testing simulates concurrent players against your infrastructure to find where it breaks before real players do. It answers questions no amount of code review can: at what concurrency does your architecture break, when does allocation start queuing, and what fails first. The point is to find the ceiling deliberately.
Also called
load test
,
What Is Load Testing, and Why Is a Spike the Hard Test for Games?
Load testing is a family of tests, each answering a different question. The k6 documentation lists six (Grafana k6):
Test | What it checks | What it looks like for a game |
|---|---|---|
Smoke | Whether the scripts and setup work | A few matches, start to finish |
Average load | Behavior at typical traffic | A normal daily peak |
Stress | Behavior above normal traffic | Twice the expected peak |
Spike | A sudden surge | An event start or a launch hour |
Soak | Stability over a long time | Hours or days, to catch leaks |
Breakpoint | Where it stops working | Keep adding matches until something fails |
This page focuses on the spike, which is likely the hardest of the six for a multiplayer game. A surge of players is a surge of matches, and each match needs its own server, started on demand and kept for minutes or hours. Take 2,000 concurrent players in matches of four: that is 500 servers running at once. If 20 new matches start every minute and each lasts about 25 minutes, 500 servers are online at peak. A spike raises the arrival rate, so the matchmaker, the server requests and the notifications all feel it at the same moment.
A spike is also not instant. Players arrive in waves, and creating a thousand servers in one second mostly proves that the request limits will refuse you. So shape the surge the way real traffic behaves:
Ramp steeply, not instantly. Start slowly, climb in steps, then hold.
Add randomness. Do not create servers on exact second boundaries, because real matches form with natural variance.
Vary the length of matches. Some end quickly and some run long, so capacity frees up unevenly.
Spread players out. Players come from several regions, which affects where servers are placed.
Hold it long enough. Short bursts hide the problems that appear after hours.
The other five tests follow from the same shape: change the height of the ramp, or the length of the hold.
What Should a Game Load Test Cover?
More than the game server. A match passes through a chain, and the weakest link sets the ceiling:
Stage | What can break | What to watch |
|---|---|---|
Matchmaker | Tickets queue up, groups form slowly | Time from ticket to match |
Allocation | The request for a server is delayed or refused | Time from "match found" to "server ready", error rate |
Notification | The backend misses the "server is ready" message | Missed or duplicate notifications |
Backend and database | Slow queries, exhausted connections | Query time, errors |
Game server | Memory leaks, tick rate drifting under load | Tick time, memory over hours |
Cleanup | Servers left running after the match | Leftover servers |
Memory leaks, slow database queries and inefficient netcode are typical findings, and none of them shows up if the test only asks a server to start.
Test the chain you will actually run. A test that skips the matchmaker and calls the allocation API in a loop checks the API, not your launch. Matchmaker covers how real players queue, and scalability covers how to size the target.
Which Load Testing Tool Should You Use for a Game?
Three open source tools cover most teams, and the choice is mostly about how your team likes to write tests:
Apache JMeter has a visual interface and built-in reports, so it suits teams that prefer to build scenarios without code. It supports HTTP and TCP, among others, and can run distributed.
k6 writes tests in JavaScript, so they live in version control and run in a CI pipeline.
Locust writes tests in Python and can run distributed across machines.
All three are good at one job: driving the HTTP side of your stack, such as matchmaker tickets, server requests and webhook handlers. None of them plays your game. To test the connection itself you need client bots, and that is the real decision. Edgegap's guide treats it as optional but valuable: bots that connect to each ready server show whether a server that reports "ready" accepts players, and the cheaper fallback is to test raw network connectivity to each server's address and port (article 246). Bots cost engineering time, and a connectivity check cannot tell you whether the match plays correctly.
How Do You Run the Test and Clean Up After It?
Start from a profile that matches your launch, then adapt it. Edgegap's guide gives three, each with a ramp followed by a hold (article "How to run a Load Test for any Multiplayer Game"):
Profile | Concurrent players | Players per match | New matches a minute | Ramp, then hold |
|---|---|---|---|---|
Indie launch | 200 | 2 | 5 | 10 minutes, then 60 minutes |
Mid-size title | 2,000 | 4 | 20 | 20 minutes, then 90 minutes |
Beta weekend | 10,000 | 6 | 50 | 30 minutes, then 2 to 4 hours |
The target itself comes from a forecast, covered in scalability. Then run it in five phases, and the details below use Edgegap's API as the worked example.
Prepare test clients. A simplified version of your matchmaking backend that forms matches, requests servers, handles notifications and records every event.
Ramp server creation. Follow the curve above and watch for rate limit errors.
Track readiness. Measure the time from request to "ready", and investigate every server that never gets there.
Connect players. Bots if you have them, a raw connectivity check if you do not.
Clean up and validate. End the matches, then scan for servers that were left behind.
Rate limits. Edgegap's API documentation lists 40 requests a second for deployments and 20 for the status and context endpoints, per organization, as of 13 October 2026. Above that, requests get an HTTP 429 response. Back off exponentially and honor a Retry-After header if one is returned, as the guide advises, and spread requests over time rather than sending bursts.
Notifications. Webhooks fire when a server is ready, fails to start or is terminated. They are not retried, so your handler must tolerate a missed message and a duplicate one, and your backend should keep its own record of each server's state. Keep the status endpoint as a fallback, because polling hundreds of servers burns through the rate limit.
Cleanup. A server ends when your backend deletes it, when the game server stops itself, or when a maximum duration runs out. Tag every test server so you can find it later, and treat a leftover server as a bug in your cleanup, because it inflates cost and skews the next run.
A word from our sponsor (ourselves!)
Most studios find their scaling ceiling at launch, in front of players. Edgegap reached 14 million concurrent sessions in a one-hour benchmark on real game server containers, so the limit you plan around is your game's, not your host's.
Edgegap's Take (just our opinion, take it with a grain of salt!)
Run the Load Test Before Launch, Cover the Whole Chain, and Warn Your Provider First
A load test is a rehearsal, so it pays off only if it runs early enough to change something. A dry run a few weeks before launch leaves time to fix what it finds. A run the night before leaves time only to worry.
Cover the whole chain, because the ceiling is usually the weakest link outside the game build, such as the notification handler, the database or the matchmaker settings.
And tell your provider first. For a large test, Edgegap asks for notice, because it can pre-scale capacity and raise rate limits for the test window. Without it, you may end up measuring a provider's cold start instead of your own system. Our guide's thresholds are more than 20 deployments a second sustained, or around two hours at peak (article 246). Sizing the target is covered in scalability.
There is a cost: a realistic test takes engineering time, a staging setup and some lead time for the heads-up. A small game with a few hundred players may not need all of it. For a launch where downtime is expensive, we think skipping it costs more. In Edgegap's 2023 benchmark, 40 deployments a second held for 60 minutes reached 14 million CCU across 550+ locations at the time (benchmark).
,
