Understanding Minecraft Server TPS: Why Your World Lags and How to Fix It

Minecraft server TPS (ticks per second) measures how many times the game world updates every second, and a healthy value sits at 20 TPS with each tick completing in under 50 milliseconds. When that budget is exceeded, mobs move slower, redstone misfires, and hoppers stall. Tick lag comes from entity counts, chunk loading, heavy redstone, view distance, and single-core CPU speed, all of which you can diagnose with a timings report and correct through targeted configuration changes.

Minecraft server TPS: how the tick loop actually works

Every Minecraft instance runs on a single main thread that processes one tick every 50 milliseconds, which produces the target of 20 ticks per second. Inside that window, the game moves entities, checks block updates, runs redstone circuits, handles player input, and saves chunk data. If all of that work finishes early, the thread waits out the remaining time before starting the next tick.

When the workload takes longer than 50 milliseconds, the server cannot wait, it simply runs behind. This is called tick lag, and it shows up as TPS dropping below 20. The console command /tps reports averages over the last one, five, and fifteen minutes, which helps you see whether a drop is a brief spike or a sustained problem.

MSPT (milliseconds per tick) is the companion metric worth tracking alongside TPS. TPS caps at 20 and hides how close you are to the limit, while MSPT keeps climbing and shows the real margin left before the next tick misses its deadline.

If you want to test view distance and simulation distance changes on a clean Paper or Purpur build before touching your live world, starting a separate environment through Minecraft server hosting lets you run timings reports and compare settings without risking your existing save.

What causes tick lag: entity counts, chunk loading and redstone

Three sources account for most tick lag reports: too many entities, chunks loading faster than the server can generate or read them, and redstone circuits that recalculate constantly. Each one stresses a different part of the tick loop, so fixing them requires different settings.

Entity counts and mob farms

Every zombie, item drop, arrow, and boat is an entity the server must update each tick. Automatic mob farms and item collection systems that pile up drops on the ground are a common culprit, since hundreds of stacked items still get processed individually.

Paper and Purpur builds let you cap entities per chunk and set despawn ranges through paper-world-defaults.yml. Lowering the entity activation range also reduces how far the server bothers to simulate distant mobs in detail.

Chunk loading and generation

Newly explored terrain has to be generated or read from disk, which is one of the heaviest single operations a tick can perform. Players scattered across a large map, elytra flight, or a exploration-heavy community push the server into constant chunk generation.

Pre-generating the world with a tool like Chunky before players arrive moves that cost off the live tick loop and into an offline, controlled process. This alone resolves a large share of chunk-related TPS drops on survival maps.

Redstone contraptions

Large redstone builds, especially clocks running every tick, hopper chains, and item sorters, force block updates that repeat continuously whether anyone is watching or not. A single unoptimized farm left running in an unloaded but still ticking area can quietly drag TPS down for the whole world.

Reducing hopper transfer frequency, replacing constant clocks with observer-based pulses, and disabling farms that aren't in active use are direct fixes. The random-tick-speed setting in server.properties also controls how often crops, fire, and leaf decay get checked.

View distance, simulation distance and single core CPU speed

View distance controls how many chunks are sent to each connected player, while simulation distance controls how many chunks are actively ticked around them. Both values multiply the workload per player, so raising either one on a populated world has a direct, measurable cost.

A view distance of 10 might feel generous for a small group but becomes expensive once ten or more players spread across the map each pull their own radius of loaded chunks. Simulation distance is usually the heavier setting since it governs entity and block ticking, not just terrain rendering.

Because Minecraft's main tick loop is effectively single threaded, raw core count matters far less than the clock speed and instructions-per-cycle of a single core. A CPU with fewer, faster cores such as a Ryzen 9 7950X3D will sustain higher TPS on a busy world than a CPU with more cores running at a lower clock, since only one core ever handles the tick loop itself.

Quick reference: TPS ranges and what they mean

TPS range	What it means in game
19 to 20	Normal, no perceptible lag
15 to 18	Minor rubber-banding, hoppers slightly delayed
10 to 14	Noticeable mob and redstone slowdown
Below 10	Severe lag, block breaking and combat feel unresponsive

Diagnosing TPS drops with timings reports and profilers

A timings report breaks down exactly how much of each tick is spent on plugins, entities, tile entities, and world generation. On Paper or Purpur builds, running the command below generates a shareable link with the full breakdown.

/timings report

Reading the output, look for any single plugin or category consuming a disproportionate share of tick time compared to the others. A plugin taking more than a few milliseconds per tick on average, across many ticks, is a strong lead worth investigating first.

Spark is a more granular profiler that many admins run alongside or instead of the built-in timings tool, since it can sample the CPU, memory, and even individual methods over a chosen window.

/spark profiler start
/spark profiler stop
/spark tps

Cross-reference the profiler output with server logs and the console output from /tps taken at the same moment the drop was reported by players. A drop that lines up with a specific player joining, a farm being activated, or a scheduled backup running points you straight to the cause.

Server settings and configuration fixes to restore stable TPS

Once you've identified the bottleneck, most fixes are configuration changes rather than plugin removals. Start with the values in server.properties that scale directly with player count and world size.

view-distance=8
simulation-distance=6
max-tick-time=60000
random-tick-speed=2

Lowering view distance and simulation distance by even one or two chunks often recovers several TPS on a populated world, since the saving applies per connected player rather than once globally.

On Paper or Purpur, paper-world-defaults.yml exposes entity caps, activation ranges, and hopper timing settings that don't exist in vanilla server.properties. Applying a moderate entity cap per chunk prevents a single farm or mob grinder from dominating a tick.

entities:
  spawning:
    per-player-mob-spawns: true
  activation-range:
    animals: 24
    monsters: 24
hopper:
  cooldown-when-full: true

Finally, keep the server software itself current. Each Paper or Purpur update typically ships tick-loop optimizations that reduce baseline load without requiring any setting changes on your part, so staying on an outdated build leaves free performance on the table.

Conclusion

Treat TPS drops as a diagnostic problem, not a hardware complaint: pull a timings report before changing anything, since guessing which setting to lower wastes time and often hides the real cause. Fix chunk generation and entity caps first, they resolve most cases, then adjust view and simulation distance only if the profiler still points to per-player load.

FAQ

Does adding more RAM fix low Minecraft server TPS?

Not directly. RAM prevents crashes and garbage collection pauses caused by running out of memory, but the tick loop itself is bound by CPU speed, not by how much memory is available. A server with plenty of spare RAM can still run at low TPS if the main thread is overloaded by entities, chunk generation, or redstone.

Why does my server show 20 TPS but still feel laggy to players?

TPS caps at 20 and hides how close the server actually is to missing its deadline, so checking MSPT alongside TPS gives a clearer picture. Client-side lag from a player's own connection, packet compression settings, or network latency can also feel like server lag even when the tick rate itself is perfectly stable.

Can a Minecraft server run smoothly on a VPS with limited CPU allocation?

Yes, as long as the allocated cores have a strong single-core clock speed, since Minecraft's tick loop only uses one core regardless of how many are available. On a shared or resource-limited VPS, keeping view distance, simulation distance, and entity counts conservative matters more than on dedicated hardware with headroom to spare.