Comprendre et stabiliser les TPS d'un serveur Minecraft

Minecraft server TPS is the single number that tells you whether your world is running smoothly or grinding through molasses. When players report rubber-banding, delayed hopper transfers, or mobs frozen mid-air, the root cause almost always traces back to a drop in ticks per second. This guide breaks down what actually drives the tick loop, how to read timings and spark reports like a technician, and which world, entity and chunk settings bring you back to a stable 20 TPS.

How Minecraft server TPS actually works

Minecraft runs on a single-threaded game loop. Every tick, the engine is supposed to process physics, redstone, entity AI, block updates, and world saving in exactly 50 milliseconds. Twenty of these ticks per second gives you the famous 20 TPS baseline. When the loop can't finish its work within that 50ms budget, the server doesn't crash — it simply falls behind, and Minecraft server TPS drops below 20. This is what players feel as "lag," even though it's rarely a network issue at all.

It's important to separate two different problems that get lumped together under "lag":

• Tick lag (low TPS): the server-side simulation is slow — this guide's topic.
• Network latency (ping): packets take time to travel between the client and the machine running the world.

A server can have excellent ping and still suffer from terrible Minecraft server TPS if the CPU core handling the main thread is overloaded by entities, chunk generation, or plugin logic. Conversely, a perfectly optimized world can still feel laggy to a player on a poor connection. Diagnosing the right problem first saves hours of wasted tweaking.

If you're setting up a fresh world and want a platform built around Ryzen CPUs and NVMe storage specifically to keep the main thread fed without I/O bottlenecks, check out Minecraft server hosting before you start layering mods and plugins on top.

Reading timings and spark reports to find the real bottleneck

Guessing which plugin or mod is eating your tick budget is a waste of time. Two tools exist specifically to answer that question with data instead of opinions.

Spark profiler

Spark is the standard profiling plugin/mod for Paper, Spigot, Forge and Fabric environments. It samples the main thread over a time window and produces a shareable report showing exactly which method calls consume CPU time.

/spark profiler --timeout 120
/spark tps
/spark health

Run the profiler during a period when players actually report the slowdown — a static 10-second sample during an empty world tells you nothing. Once it finishes, spark gives you a link to a flame graph. Look for wide bars under categories like entityTick, tileEntityTick, or a specific plugin's listener — those are your actual offenders, not the ones you assumed.

Timings reports (Paper/Spigot)

Older but still useful on Spigot-based builds:

/timings on
/timings paste

The resulting report breaks down tick time by plugin, event handler, and even per-world. A plugin responsible for more than a few percent of total tick time during normal play is worth investigating or replacing.

Reading the TPS command itself

/tps
TPS from last 1m, 5m, 15m: 19.8, 18.2, 15.4

Don't just look at the current number — compare the 1m, 5m and 15m averages. A server that recovers quickly after a spike (farms activating, a chunk border generating) behaves very differently from one in sustained decline, which usually points to a memory leak, an unbounded entity count, or a world border that keeps forcing new chunk generation.

MSPT: the number that matters more than TPS

TPS caps out at 20 and hides how much headroom you actually have. Mean Server Ticks Per second (MSPT) shows raw milliseconds per tick:

• Under 50ms: healthy, full 20 TPS.
• 50–80ms: minor overload, occasional stutter.
• Over 100ms: the main thread is structurally overloaded, not just experiencing a temporary spike.

World, entity and chunk settings that restore a stable Minecraft server TPS

Once profiling tells you where the time goes, these are the configuration levers that reliably bring Minecraft server TPS back up without gutting gameplay.

Entity and mob caps

Uncontrolled mob farms are the single most common cause of tick death on survival worlds. In paper-world-defaults.yml (Paper/Purpur):

entities:
  spawning:
    monster-spawn-max: 50
    animal-spawn-max: 10
    per-player-mob-spawns: true
tracking-range-y:
  entities: 48

Per-player mob spawns scale caps with the number of connected players instead of applying a flat server-wide cap, which keeps small communities from being punished by limits designed for large ones.

Entity activation range

Entities far from any player shouldn't run full AI ticks. Tightening activation range cuts CPU cost dramatically on large explored worlds:

entity-activation-range:
  animals: 16
  monsters: 24
  misc: 8
  tick-inactive-villagers: false

Chunk management

View distance and simulation distance are two different settings that get conflated constantly. View distance controls what's rendered to the client; simulation distance controls what actually ticks on the server:

# server.properties
view-distance=8
simulation-distance=6

Dropping simulation distance by even one or two chunks per player, on a populated server, often recovers more TPS than any single plugin change. Pre-generating the world's explored area with a chunk pre-generator also removes the generation spikes that cause sudden MSPT jumps when players explore in groups.

Redstone and random tick speed

Large redstone contraptions and dense farms built around random block ticks (crop growth, leaf decay, fire spread) scale badly. Lowering random-tick-speed in server.properties reduces the number of blocks checked per tick:

random-tick-speed=2

Default is 3; dropping to 2 is barely noticeable for crop growth but meaningfully reduces block-tick load on farm-heavy survival worlds.

Hopper and container optimization

Hopper chains moving items every tick are notoriously expensive. Paper exposes a cooldown setting that spaces out hopper transfers without breaking sorting systems:

hopper:
  cooldown-when-full: true
  disable-move-item-when-full: true

Quick reference table

Symptom	Likely cause	Fix
TPS drops only near farms	Entity or hopper overload	Lower mob caps, add hopper cooldown
TPS drops during exploration	Chunk generation	Pre-generate world, lower view/simulation distance
TPS declines slowly over days	Memory leak or unbounded entity growth	Restart schedule, profile with spark, check plugin logs
TPS fine, players still complain of lag	Network latency, not tick lag	Check ping separately from /tps

Hardware still matters

Because the main thread is single-core bound, raw clock speed beats core count for Minecraft server TPS stability — this is exactly why high-frequency Ryzen CPUs make a measurable difference over older or shared architectures. NVMe storage also matters more than people expect: region file reads and writes during chunk generation and autosaves hit disk constantly, and slow storage shows up as periodic MSPT spikes that look like code problems but are actually I/O waits. Anti-DDoS protection won't change your TPS, but it does prevent a flood attack from being mistaken for a tick performance issue when the real cause is saturated network buffers.

For a deeper technical reference on the tick loop and profiling tools, see the Paper profiling documentation.

Automated backups are worth mentioning here too: before touching entity caps, simulation distance, or any world-altering plugin, take a fresh snapshot through your panel's backup feature so a misconfigured value never costs you actual world progress. Browse the full catalog of game server environments or compare orchestration options on a Pterodactyl environment if you manage multiple worlds from one control plane.

Stable tick performance comes down to measurement before modification: profile with spark, read MSPT alongside TPS, then adjust entity caps, simulation distance and random tick speed based on what the data actually shows. Treat hardware, world settings and plugin audits as one connected system rather than isolated fixes.

FAQ

Why does my TPS drop only when several players are online at once?

Per-player mob spawn caps and simulation distance scale with player count. Check your entity caps in paper-world-defaults.yml and consider lowering simulation-distance slightly, since each additional player adds ticked chunks and entities around their position.

Is a low TPS always caused by plugins or mods?

No. Run a spark profile first — vanilla causes like dense redstone, uncapped mob farms, and chunk generation during exploration are just as common as poorly optimized plugin code. Profiling tells you which it is before you start removing content.

Will restarting fix a gradual TPS decline?

Often yes, if the cause is a memory leak or accumulating entities, but it's a temporary patch, not a fix. Use the restart to buy time, then profile the next session to find what's growing unchecked and address it at the source.