Measuring Minecraft Server Performance: TPS, MSPT and Tick Health

The tick loop, and why 50 milliseconds is the number that matters

A Minecraft server is a single loop. On every iteration — a tick — it advances the world by one step: mobs decide what to do, redstone updates, water spreads, crops grow, entities move, chunks load and unload, and player actions are applied. The server targets 20 ticks per second, which gives each tick a budget of exactly 50 ms.

If a tick finishes in 12 ms, the server sleeps for the remaining 38 ms and starts the next one on schedule. If a tick takes 70 ms, there is nothing to sleep off — the server is already late, and the next tick starts behind. Sustain that and the tick rate drops below 20, at which point the entire world slows down: furnaces smelt slower, mobs move in stutters, and hit registration goes soft.

TPS is a ceiling, not a gauge

TPS (ticks per second) is the metric everyone quotes, and it is the less useful of the two. The problem is that it is capped: a server whose ticks take 5 ms and a server whose ticks take 49 ms both report a flat 20.0 TPS. One has 90% headroom, the other has 2%, and TPS cannot tell them apart.

By the time TPS moves, the server has already failed. It is a lagging indicator that only reports damage after it has happened.

MSPT is the metric to watch

MSPT — milliseconds per tick — is the actual time each tick consumed. Because it is uncapped, it shows the headroom TPS hides, and it degrades gradually enough to act on. Run /tps on Paper or /spark tps on any modern server and you will get both figures.

Watch the distribution, not just the average. A server averaging 20 ms with regular 60 ms spikes feels considerably worse to play on than one sitting steadily at 32 ms, because the spikes are what players perceive as lag. Spark reports 95th and 99th percentile MSPT for exactly this reason — treat the 95th percentile as the honest number.

Why single-thread CPU performance decides everything

The main tick loop is fundamentally serial. Modern server software (Paper, Purpur, Folia) has moved chunk generation, pathfinding and I/O off the main thread, but world simulation itself still runs in one sequence, because block updates are order-dependent. A redstone circuit has to resolve in a defined order to behave predictably.

The practical consequence is that a 32-core server CPU with a modest per-core clock will lose to a consumer chip with high single-thread performance. This is precisely why serious hosts advertise the exact CPU model — a Ryzen 9 7950X or 9950X rather than “enterprise-grade hardware.” When a provider will not name the chip, that silence is information.

Where the tick budget actually goes

When MSPT climbs, the cause is usually one of a small set of culprits. In rough order of how often they turn up:

• Entity count. Mob farms, item stacks on the floor, minecart networks and armour stands. Every entity is ticked, and the cost scales linearly.
• Chunk loading. Players flying at speed through ungenerated terrain force generation on the critical path. Pre-generating the world border removes most of this.
• Redstone and hoppers. Hopper chains poll constantly; large contraptions can dominate a tick on their own.
• Plugin and mod overhead. A single plugin doing synchronous database queries or filesystem access inside a tick will stall the whole loop.
• Garbage collection pauses. Visible as periodic spikes at a regular interval rather than sustained load.
• Noisy neighbours. On oversold shared hardware, your MSPT rises because someone else's server is busy. You cannot fix this from inside your server.

A profiler distinguishes these in minutes. Spark is the standard tool: /spark profiler start, leave it running through a busy period, then /spark profiler stop for a shareable call-tree showing exactly which method consumed the tick.

Benchmarking a host before you commit

Provider marketing is not evidence. A usable test takes about an hour on a monthly plan, and every host worth using offers one:

• Establish a baseline. Fresh world, no players, no plugins. Record idle MSPT. Anything above 5 ms on an empty server means the hardware is already oversubscribed.
• Load a realistic world. Upload the world and plugin set you actually intend to run. Synthetic tests on a fresh superflat prove nothing.
• Force chunk generation. Fly on Elytra along an unexplored axis and watch MSPT. This is where oversold hardware fails first.
• Test at peak, not at 3 a.m. Shared-hardware contention shows up in the evening. A benchmark run at a quiet hour measures the wrong thing.
• Sample over days, not minutes. Spark and bStats can log continuously. A week of data will show whether performance is stable or merely was when you looked.
• Time the support desk while you are at it. Open a genuine technical ticket during the trial and record the response. It is the one specification you can verify directly, which is why we track it in the comparison table.

What the numbers cannot tell you

Tick metrics measure the server, not the connection. A server holding a steady 18 ms MSPT still plays badly if the route to it adds 180 ms of network latency, so check round-trip time from where your players actually are — not from wherever you happen to be sitting. Similarly, MSPT says nothing about how quickly a corrupted world can be restored. That is a backup policy question, and it matters more than a couple of milliseconds on the tick loop the day something goes wrong.

Summary

• Each tick has a 50 ms budget. MSPT is how much of it you are using.
• TPS is capped at 20 and only moves after the server has already failed.
• Aim to stay under 25 ms MSPT at the 95th percentile, not just on average.
• Single-thread CPU performance dominates; extra RAM rarely helps.
• Profile with Spark before changing anything — guessing wastes more time than measuring.
• Benchmark on a monthly plan, with your real world, at peak hours, before committing.