Minecraft TPS vs MSPT: what actually tells you the server is struggling?
TPS describes the pace of the simulation. MSPT describes the work needed to run its ticks. Read them together before deciding which part of your server needs attention.
Start with the tick budget.
A standard Minecraft server aims to process 20 ticks each second. That leaves an average budget of 50 milliseconds per tick. When processing repeatedly exceeds that budget, the simulation cannot maintain its target pace.
These numbers describe server simulation, not a player’s frame rate or connection latency. A player can have low FPS while the server maintains healthy ticks, or a good connection to a server whose simulation is overloaded. Ask which symptom is present instead of using “lag” as a single diagnosis.
| Metric | What it describes | What it does not prove |
|---|---|---|
| TPS | Simulation ticks completed each second. | The cause of slow ticks. |
| MSPT | Time spent processing ticks. | That one named mod is at fault. |
| Ping | Network round-trip latency. | Server tick cost or client rendering. |
| FPS | Client frames rendered per second. | The health of the server tick loop. |
20 TPS can still leave little headroom.
TPS is capped by the normal target, so a server processing ticks quickly and one close to its budget can both report 20 TPS. MSPT helps distinguish those situations. A heavily modded server near the limit can become sensitive to exploration, a busy base or a scheduled task.
Do not treat any single average as a complete health score. Look at the capture window and the distribution of tick durations where that information is available. A short severe stall may be much more noticeable than the average suggests.
Treat spikes and sustained pressure differently.
For sustained pressure, capture normal busy play and look for work that stays expensive across the period. For intermittent stalls, identify the activity or timing first. A capture that mostly records idle time may make a rare expensive action difficult to see.
A spike-filtered Spark capture answers a different question from an unfiltered baseline. Keep its threshold and capture conditions in your notes. Comparing different profiling modes without that context can lead to a false conclusion about whether a fix helped.
Read report estimates with their context.
TickVisor turns uploaded diagnostics into a report with performance grading, grouped systems and attribution signals. Timing values may be estimated depending on the source data. Use the report’s timing confidence and preserve the original capture for deeper verification.
A percentage is a share of recorded work. If entity ticking rises from 30% to 40%, that alone does not prove entities became slower: other work may have fallen. Compare total tick pressure, workload and the method used to record it.
Choose the investigation from the symptom.
When tick cost is high, inspect a server-side Spark capture. When ticks remain healthy during the complaint, investigate the affected client or network path instead. If a crash or repeated error occurs, add the relevant log as supporting context.
After one controlled change, repeat the same kind of capture under comparable activity. Record players, dimensions, loaded automation and any profiling filter. This is more useful than comparing two unrelated moments.
- Record tick pressure during the complaint.
- Decide whether the problem is constant or intermittent.
- Preserve capture settings and filters.
- Compare a second capture after one change.
Common questions
Does 20 TPS prove a server has no performance problem?
No. Check MSPT, headroom, spikes and the symptom itself. TPS alone does not describe client FPS or network latency.
References and further reading
Commands and platform behavior can change. Check the official documentation for your installed versions.
Turn your next capture into a clearer decision.
TickVisor analyzes uploaded files. You choose the fix and validate it with another capture.