Minecraft TPS and MSPT explained: How to read a spark profiler
TPS tells you whether the server keeps time. MSPT tells you how much of each 50 ms tick budget it uses. spark helps identify where that time went.
A healthy Minecraft server targets 20 ticks per second. That gives each tick a 50 millisecond budget. TPS shows whether the server keeps that schedule, while MSPT shows how long its work takes. When sustained MSPT exceeds 50, the server cannot maintain 20 TPS.
The useful next question is not “how do I raise TPS?” It is “what consumed the tick?” That is what a profiler answers.
TPS: the outcome
Ticks advance mobs, redstone, block updates, scheduled plugin tasks, and other server state. At 20 TPS, 100 ticks take five seconds. At 10 TPS, the same scheduled 100 ticks take roughly ten seconds.
TPS is capped at 20, so it hides spare capacity. Two servers may both report 20 TPS while one uses 8 ms per tick and the other uses 45 ms. They have very different headroom.
MSPT: the budget in use
Milliseconds per tick exposes that headroom:
| MSPT | Interpretation |
|---|---|
| Under 25 ms | Comfortable room for bursts |
| 25–40 ms | Healthy, but watch peak behavior |
| 40–50 ms | Close to the limit |
| Over 50 ms | Cannot sustain 20 TPS if it persists |
These bands are operational guidance, not guarantees. Short spikes can occur during saves, startup, teleports, or chunk generation without creating a persistent player problem.
Capture the problem while it happens
Paper's documentation says profiling is effective only while the issue is active. Current Paper releases bundle spark and prefer it over the older timings system.
Start a ten-minute profile during the slow period:
/spark profiler start --timeout 600
When it finishes, spark returns a report URL. Treat that URL as potentially sensitive because it can expose plugin names, server details, and performance data.
How to read the report
Start at the broadest categories and follow the widest branches. The width represents sampled time, not how many times a method appears.
Look for:
- A plugin occupying a large share of the server thread.
- Entity ticking dominated by one mob or block-entity type.
- Chunk generation or loading during exploration.
- Frequent garbage collection paired with a filling heap.
- Database or file work performed synchronously on the main thread.
Do not delete the first plugin named in a stack trace without understanding the call path. A scheduler may invoke plugin work, and a plugin may invoke server work. The expensive operation is deeper in the branch.
Profile before and after one change
Change one variable, reproduce the same workload, and capture again. Useful comparisons include:
- Before and after disabling one suspected plugin on a copy.
- Normal view distance versus a lower value.
- Live exploration versus a pre-generated world.
- Quiet-hour and peak-hour results with the same players and actions.
The last comparison matters for hosting. If your own sampled work is stable but ticks stall only when the physical machine is busy, investigate CPU contention and steal time.
Where gummysnacks fits
The gummysnacks companion reports live TPS into the customer panel, so a drop is visible without installing a separate dashboard. The panel metric is an alert and history signal, not a replacement for spark. Use spark when you need method-level evidence.
If memory looks suspicious, use the RAM sizing guide and calculator. If a failure ends the process, continue with the crash troubleshooting guide.
Sources and review
Reviewed July 15, 2026 against the official Paper profiling guide, spark documentation, and Paper's explanation that a normally running server schedules 20 ticks per second in its plugin lifecycle documentation.