The 50 millisecond budget
Think of each tick as a budget: 50 ms to handle movement, entities, block updates, and redstone before the next tick is due. Under budget, the server has headroom; over budget, ticks stretch and the world slows.
Target staying comfortably under, not merely at, the limit. A server running at 45 ms is technically healthy but has no room for a farm firing or several players exploring at once.
Steady load versus spikes
Constant high MSPT points at ongoing cost: too many entities, an oversized view distance, or a plugin doing work every tick. Spiky MSPT usually means something periodic — chunk generation, a scheduled save, or a redstone clock.
That distinction decides your fix. Lowering distances helps the first; pre-generating chunks or taming a machine helps the second.
Where to find MSPT
Paper exposes it directly, including per-world breakdowns. On vanilla, spark or the panel’s performance graph is the practical route, and /debug produces a report you can read from the world folder.
Whatever the source, record the number and the conditions — who was online, what was running — or the reading means nothing later.
Using MSPT to decide
Change one thing, then compare MSPT under similar conditions. If it improves and nothing broke, keep it; if nothing moved, revert and stop guessing. That loop is the entire discipline of server optimisation.
When MSPT is healthy and players are content, further tuning is pure risk. The goal is a server nobody has to think about.
FAQ
Common questions
What MSPT should a healthy server have?
Under 50 ms, and ideally with margin — 20 to 35 ms leaves room for busy moments. Sustained values above 50 mean the server is missing ticks and players are feeling it.
Why is MSPT better than TPS for diagnosis?
Because TPS is an average over time and hides brief spikes, while MSPT shows how close the server is to its limit right now. Spikes are what players notice, so measuring them directly is more useful.
