What Are Minecraft TPS and MSPT?

TPS is the number of simulation ticks a Minecraft server completes per second. MSPT measures the milliseconds spent processing a tick. At the normal 20 TPS target, a tick has a 50 ms budget. Sustained work above that budget slows the simulation; high network ping can make play feel delayed even when the server maintains 20 TPS.

Use this guide for a conventional Java server running at the default tick rate. Modified tick rates and region-threaded implementations need their own interpretation. A dashboard average is a clue, not a complete performance diagnosis.

How do TPS and MSPT fit together?

Illustrative tick-budget examples, not EnderHost measurements
Observation	Interpretation	Next check
20 TPS and 15 ms tick work	Work fits within the normal tick budget.	Check spikes if players still report pauses.
20 TPS with occasional long ticks	An average can hide brief stalls.	Inspect the tick-time distribution and a busy-period profile.
Sustained 75 ms tick work	Work cannot fit into 50 ms consistently.	Find the workload occupying the tick thread.
20 TPS and high ping	Simulation may be healthy while delivery is delayed.	Compare affected players and network routes.

For a simplified steady workload, 1,000 divided by 75 ms is about 13.3 ticks per second. That arithmetic explains the budget; it is not a prediction of a live server’s exact TPS. Scheduling, pauses and the averaging window affect the displayed number.

How to collect a useful performance snapshot

Paper includes spark starting with Minecraft 1.21. Other software or older versions may require a compatible installation. Use the documentation for your build instead of installing a second profiler blindly.

Write down the server software/build, Java version, player count and what players are doing.
During the problem, record tick metrics and start a short profile. An idle-server capture cannot explain a busy-server problem.
Repeat during a healthy period with similar activity. Keep the two reports labeled by time and configuration.
Record view and simulation distance, recent plugin changes and whether players are generating new chunks.

/spark tps
/spark profiler start --timeout 120

These are in-game administrator commands. In a server console, omit the leading slash where the console expects bare commands. The profiling timeout above requests a two-minute sample; extend the observation window if the event does not happen during it. Check the report for private information before sharing it publicly.

Why does low total CPU usage not rule out server lag?

A busy serial task can be the limiting factor while other cores are idle. A machine-wide CPU percentage averages across available execution capacity. Inspect the relevant thread and profiler trace instead of concluding that unused aggregate CPU means the application can run faster.

Low TPS also does not establish that you need more RAM. Check the heap and memory-limit guide for allocation pressure; use latency diagnostics when the server is keeping up but particular players are delayed.

What should you change after measuring?

Follow the work identified by the profile: a plugin callback, entity processing or chunk generation may need different changes. The existing Minecraft performance tuning guide covers the next investigation steps. Back up configuration and world data before testing changes.

Use the same workload for a before-and-after comparison. Record both responsiveness and gameplay effects: reducing simulation distance may reduce work while changing how distant farms behave. Keep the change only if it meets the server’s actual goals. If the remaining constraint is hardware, bring the reports to a hosting discussion rather than buying a larger allocation solely because it exists.