Method document
Test rig plan: hardware, regions, bots and profilers
No GameServerBench test rig exists. This page records what one would need to contain, so the design can be challenged before money is spent on it. Nothing below has been built, bought or run.
What the rig has to do
A rig has one job: generate the same load against every host and record what happens, while staying out of the way of the thing being measured. That leads to three requirements.
The client must not be the bottleneck. Load clients would run on separate machines from the server being measured, with enough headroom that a slow reading can't be blamed on the client. A dry run against a known machine would have to show this before any host run counts.
Identical runs must agree. The harness would first run on hardware the site owns, twice, with the same world and load. If two runs on the same machine disagree by more than the differences being looked for between hosts, the harness isn't ready.
Every run must be reproducible from its record. Versions, flags, world copy, load script, start time and client location are saved with the output.
Planned components
| Component | Planned tool | What it records | Known limit |
|---|---|---|---|
| Minecraft tick time | spark, bundled with Paper from 1.21 | TPS, MSPT, profiler output | Readings describe the server process, not the host as a whole |
| Palworld frame time | REST API metrics | serverfps, serverframetime, player count, uptime | Reports FPS and frame time, not TPS, so no cross-game comparison |
| Other games | The game's own console or log output, chosen per game | Game-specific tick or frame reading | Undecided until each game is reviewed |
| Minecraft bots | SoulFire, if permitted | Simulated logins and movement | Its README limits use to servers you own or have permission to test |
| CPU, where shell access exists | sysbench | Synthetic CPU score | Synthetic, and many game plans give no shell |
| Disk, where shell access exists | fio | Throughput and IOPS | Results depend heavily on settings, which must be published |
| Network path | MTR | Latency and loss per hop | Its README warns that loss at an intermediate hop may not be real loss |
Most managed game plans give no shell, so a host's plan may rule out the synthetic tools. In that case only the in-game readings would be recorded, and the page would say so.
Regions
Round-trip readings need a client near each region tested. The plan is to use a small number of fixed probe locations, publish where they are, and compare a host's region only with the same probe. The latency by region page sets out how that would work.
What is not decided
The rig's hardware, its probe locations, and the tooling for games other than Minecraft and Palworld are all undecided, and no budget has been approved for any of them. Bot tools can't be run on a host until its terms are checked. Attack or flood testing is out of scope. The planned method has the full list of preconditions.