Comprendre et stabiliser les TPS d'un serveur Minecraft

Minecraft server TPS is the single number that tells you whether your world is keeping pace with real time, and when it drops below 20, players feel it instantly through rubber-banding, delayed redstone, and mobs that teleport instead of walk. Understanding what actually pushes ticks down — and which settings move the needle — turns a vague feeling of lag into a measurable, fixable problem.

What Actually Drives Minecraft Server TPS

Every world runs on a tick loop. One tick should take exactly 50 milliseconds, which gives you 20 ticks per second — the theoretical ceiling. Minecraft server TPS is simply a measurement of how many of those 50ms windows the loop manages to complete on time. If block updates, entity processing, and chunk logic take longer than 50ms, the loop falls behind and the reported TPS drops.

The tick loop is almost entirely single-threaded for world logic (entities, blocks, redstone, pathfinding). This is why single-core CPU clock speed matters far more than core count for raw tick performance — a fast Ryzen core clears the 50ms window more reliably than many slower cores spread across threads that the main tick loop can't use anyway.

Three forces compete for that 50ms budget:

• World simulation: block ticks, redstone, fluid updates, crop growth.
• Entity processing: mobs, item entities, projectiles, and their AI/pathfinding.
• Chunk management: loading, generating, and unloading chunks as players move.

If you're setting up a fresh environment specifically to test tick stability under load, our Minecraft server hosting configuration runs on Ryzen cores with NVMe storage, which removes disk I/O and clock-speed bottlenecks from the equation before you even start tuning plugins.

Reading and Interpreting Tick Timings

Before changing any setting, measure. Guessing which plugin or mob farm is responsible for a drop wastes hours; a proper timings report tells you in minutes.

The /tps command

On Paper, Spigot, and most forks, the console or an operator can run:

/tps

This returns a rolling average over 1, 5, and 15 minutes, something like 20.0, 19.8, 19.6. A healthy world sits at 20.0 across all three windows. If the 1-minute value is low but the 15-minute value is fine, you have an intermittent spike (a chunk generation burst, an explosion, a mob farm trigger). If all three are consistently low, you have a sustained load problem.

MSPT — the number that actually matters

TPS is capped at 20 and hides how bad things really are once you're already lagging. MSPT (milliseconds per tick) doesn't hide anything:

/tps
# example output
TPS from last 1m, 5m, 15m: 19.2, 19.6, 19.9
Tick times (avg/min/max) from last 1000 ticks: 46.1ms/38.0ms/210.5ms

An average near 50ms means the server is on the edge of dropping ticks. A max spike of 210ms tells you something specific is causing periodic stalls, even if the average looks acceptable.

Profiling with Spark

For a granular breakdown by plugin, entity type, or world region, the Spark profiler (bundled with Paper and available as a plugin elsewhere) is the standard tool:

/spark profiler --timeout 60
/spark tps
/spark healthreport

The generated report ranks exactly which method calls, plugins, or mob AI routines consume the most tick time — this is where you find the redstone clock nobody remembers building, or the plugin doing a full inventory scan every tick.

Settings That Keep Ticks at 20

Once you know where the time is going, the fix is almost always one of four levers: view distance, entity limits, chunk loading behavior, or raw single-core CPU speed. Minecraft server TPS responds predictably to each of them.

View distance and simulation distance

These are set in server.properties and directly control how much of the world is loaded and simulated per player:

view-distance=8
simulation-distance=6

Simulation distance (Paper/vanilla 1.18+) is more expensive than view distance because it forces full entity and block-tick simulation, not just rendering. Dropping simulation distance from 10 to 6 on a busy survival world often recovers several MSPT immediately, with a visually minor loading difference for players.

Entity and mob caps

Uncontrolled mob farms and item entity spam (dropped items, arrows, XP orbs) are the most common cause of a slow, creeping TPS decline. Useful controls, depending on your server software:

# spigot.yml / paper-world-defaults.yml examples
entity-tracking-range:
  players: 48
  animals: 32
  monsters: 32
  misc: 16

max-entity-collisions: 8
mob-spawner-tick-rate: 2

Capping entity collisions is particularly effective against boat/villager clumping, and lowering tracking range reduces per-tick packet work without meaningfully affecting gameplay for most survival configurations.

Chunk loading behavior

Chunk generation and loading spikes are usually short but severe — a player flying through unexplored terrain can force dozens of chunk generations in a few ticks. Mitigate with:

# paper-world-defaults.yml
chunks:
  max-auto-save-chunks-per-tick: 24
  entity-per-chunk-save-limit:
    default: -1
  prevent-moving-into-unloaded-chunks: true

Pre-generating the world border ahead of time (via a chunk pre-generation plugin, run once during low-traffic hours) removes this spike entirely for known exploration areas.

Single-core CPU speed

Because the main tick loop can't be split across cores, a CPU with a high per-core clock speed clears the tick loop faster than one with more, slower cores. This is one of the few tick bottlenecks you can't fix from inside server.properties — it's a hardware ceiling. Ryzen-based hardware is commonly favored for this exact reason: high boost clocks translate directly into lower MSPT under identical plugin and player load.

Quick reference table

Setting	Typical impact on TPS	Player-visible tradeoff
view-distance	Moderate	Slightly shorter render distance
simulation-distance	High	Distant redstone/farms pause when unloaded
entity tracking range	Moderate	Mobs/players render slightly closer
mob/entity caps	High on farm-heavy servers	Farm output may need rebalancing
single-core CPU speed	High, constant	None — pure headroom

Diagnosing TPS Drops Step by Step

A repeatable workflow beats trial and error. Run through this checklist whenever players report lag:

1. Run /tps and note the 1m/5m/15m values plus MSPT average and max.
2. If the drop is intermittent, run Spark for a 60-second window during the next spike and read the top consumers.
3. Check whether the report points to a plugin, a specific mob type, or world generation — each has a different fix.
4. Apply one change at a time (entity cap, simulation-distance, or a plugin config) and re-measure before making a second change.
5. If MSPT stays near 50ms even with an optimized configuration, the bottleneck is CPU clock speed, not settings — consider testing on hardware with a higher single-core clock.

Restarting after config changes is done from the console or panel:

systemctl restart minecraft-server
# or, from a management panel: use the restart action on the server instance

Keep a backup before any structural change to server.properties or a plugin config — automatic backups make this a non-issue, but manual snapshots before a tuning session are still good practice. If you manage the environment yourself rather than through a managed panel, the same profiling workflow applies over SSH on a Pterodactyl VPS instance. For a broader look at tuning other survival and multiplayer titles, browse the Fly-Serv blog or the full list of supported game servers.

Minecraft server TPS isn't a mystery once you know where the 50ms budget actually goes. Measure with /tps and Spark, then adjust view distance, simulation distance, and entity caps before touching anything else. When every setting is already tuned and MSPT still hovers near 50ms, the remaining bottleneck is almost always single-core CPU speed.

FAQ

Why does TPS drop even with few players online?

Low player count doesn't mean low tick load. Uncapped mob farms, redstone clocks, large villager populations, or excessive loaded chunks from AFK players can consume the full tick budget regardless of how many people are connected. Run a Spark profile to identify the exact source.

Does lowering render distance on the client fix server-side TPS?

No. Client render distance only affects what a single player sees locally. Server-side TPS depends on view-distance and simulation-distance in the server configuration, which control what the server itself loads and simulates for everyone.

What MSPT value should I treat as a warning sign?

Anything consistently above 45ms average is worth investigating, since it leaves little headroom before ticks start dropping. A max spike above 100ms during normal play, even with a good average, usually points to a specific recurring event worth profiling.