Run a bot load test
Before you put a server on the internet you want to know what it does under load. The sources include a bot client that connects many scripted players to a server and measures it. It speaks the same protocol a game window does, so what it shows is what real players would cost.
This is a developer tool from the sources (server/dedicated/examples/botclient.rs), not part of the editor or engine download. It needs Rust.
Build it
cd server\dedicated
cargo build --profile fast -j 3 --bins --examplesUse the same profile every time so the build is reused. The programs land next to each other in the build folder: w4-dedicated and examples\botclient.
The easy way: a private server
botclient --spawn path\to\w4-dedicated.exe --map "path\to\a map folder" --bots 32 --secs 60--spawn starts a private copy of the server on 127.0.0.1 only (so no firewall question), gives the map twelve seats, connects 32 bots, runs for 60 seconds and stops the server. The map folder must contain objects/definitions.toml. A map has at most 12 seats, so bots beyond 12 are refused with the game is full and counted as such; that is correct, not a failure.
Test a server that is already running
botclient --addr 127.0.0.1:7777 --bots 10 --secs 60 --deltaFor a server with TLS add --tls the.server.name --ca roots.pem. --insecure skips the certificate check and is only allowed for loopback.
What each bot does
Names are Bot001, Bot002 and so on. A bot says hello, reports that it has loaded, then every second sends one move order for a random unit it owns and one latency ping, timing the answer. It keeps no picture of the world. A bot that is refused or dropped does not come back; it is counted.
Options
| Option | Meaning |
|---|---|
--bots N |
how many players |
--secs N |
how long |
--delta |
ask for delta snapshots (only what changed) |
--orders-per-sec N |
orders per bot per second (default 1) |
--ramp |
add 10 bots a second instead of all at once |
--server-pid N |
read that process's CPU time, so the summary can show the server's cost |
Reading the output
Every 10 seconds one line: clients connected, megabytes per second received, snapshots and steps per second, round-trip times (median, 95th and 99th percentile), server CPU, and the counts of refused, errors and disconnects. At the end, a table per bot and totals.
What to look for:
- steps per second should stay at 30. If it falls, the server is too slow for this load, or the machine is busy.
- RTT p95 on loopback should be a few milliseconds. On a real network add the player's own delay.
- MB/s grows with the units players can see.
--deltashould cut it a lot when few units move. - disconnects should be 0. A bot that falls behind is dropped by the server, which is how the server protects itself.
A longer test
server\dedicated\examples\soak.rs runs eight scripted players for 30 minutes (four with deltas, four without), one of them reconnecting every minute, and checks that memory stays flat and the step rate never falls below 90 percent. It prints SOAK OK when it passes.
Be kind to other people's servers
Run load tests against your own server, or a private copy. Do not point a hundred bots at the official server: it has limits on purpose (256 connections, 8 per address) and has two cores that other people share.