Comprendre et optimiser le TPS d'un serveur Minecraft

Le TPS serveur Minecraft (ticks par seconde) est l'indicateur numéro un pour juger de la fluidité d'un monde en ligne : en dessous de 20, les joueurs ressentent des lags, des téléportations et des mobs qui se figent. Comprendre cette métrique permet de diagnostiquer précisément ce qui ralentit la partie avant de toucher à la configuration.

Comprendre la valeur TPS serveur Minecraft et son fonctionnement

Minecraft fonctionne par ticks : chaque tick correspond à une mise à jour complète du monde (physique, entités, redstone, IA des mobs). Le jeu vise 20 ticks par seconde, soit un tick toutes les 50 millisecondes. Le TPS serveur Minecraft mesure donc combien de ces cycles sont réellement exécutés chaque seconde. Quand le calcul d'un tick dépasse 50 ms, le moteur ralentit l'horloge interne pour compenser : c'est exactement ce qu'on perçoit comme du lag côté jeu.

Le complément indispensable au TPS est le MSPT (millisecondes par tick) : il indique le temps réel consommé par chaque tick. Un TPS affiché à 20 avec un MSPT proche de 50 ms signale un serveur à la limite, même si rien ne semble anormal en façade.

TPS observé	Ressenti en jeu
20	Fluide, aucune latence perceptible
15-19	Micro-saccades, animations légèrement en retard
10-14	Déplacements saccadés, redstone décalée
Moins de 10	Mobs figés, chutes de connexion, blocs qui n'apparaissent pas

Pour un suivi régulier de la performance d'un monde Minecraft, la mise en place d'un panel de gestion facilite la lecture des ressources CPU et RAM en temps réel, en complément des commandes en jeu. Si tu veux comparer les solutions disponibles pour ton monde, consulte la page hébergeur Minecraft qui détaille les configurations Ryzen et NVMe adaptées à ce type de charge.

Identifier les causes des chutes de TPS serveur Minecraft

Une chute de TPS n'arrive jamais sans raison. Dans l'immense majorité des cas, le problème se situe dans l'une de ces quatre familles.

Chunks chargés et distance de simulation

Chaque chunk chargé en mémoire doit être calculé à chaque tick : végétation, liquides, blocs de redstone, spawn de mobs. Une view-distance élevée combinée à une communauté dispersée sur la carte multiplie le nombre de chunks actifs simultanément, et donc le travail du thread principal.

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

Accumulation d'entités

Les fermes à mobs automatisées, les empilements d'objets au sol (item entities) et les élevages d'animaux non maîtrisés sont la cause la plus fréquente de ralentissement. Chaque entité est traitée individuellement à chaque tick : collision, gravité, IA. Un stockage de 2000 items au sol peut faire chuter le TPS serveur Minecraft à lui seul.

Nature mono-cœur du moteur de jeu

Le thread principal de Minecraft (calcul du monde, des entités, de la redstone) reste majoritairement mono-cœur, même si certaines tâches annexes sont déportées. Un processeur avec un grand nombre de cœurs mais une fréquence par cœur modeste n'apporte aucun gain ici : seule la fréquence monocœur élevée compte réellement, ce qui explique pourquoi les architectures Ryzen récentes sont privilégiées pour ce type de charge.

Plugins et scripts mal optimisés

Un plugin qui effectue des recherches en base de données de façon synchrone, scanne l'inventaire de tous les joueurs à chaque tick, ou lance des tâches planifiées trop fréquentes peut faire plonger le TPS serveur Minecraft même sur un monde peu peuplé. C'est souvent la cause la plus difficile à repérer sans outil de profilage.

Diagnostiquer précisément avec les bons outils

Avant de modifier quoi que ce soit, il faut localiser l'origine exacte du ralentissement plutôt que de deviner.

Commande native /tick query

Depuis les versions récentes de Minecraft Java, la commande en jeu permet un diagnostic immédiat sans plugin externe.

/tick query

Cette commande affiche le TPS moyen sur 5s, 10s et 1 minute, ainsi que le pourcentage de la cible de 50 ms consommé par tick.

Rapport spark pour profiler le thread principal

L'outil spark reste la référence pour identifier quelle partie du code (plugin, mob, chunk) consomme le temps de tick. Il fonctionne aussi bien sur Paper, Spigot que Fabric/Forge.

/spark profiler start
# attendre quelques minutes en charge
/spark profiler stop

Le rapport généré classe les méthodes par temps CPU consommé, ce qui permet de pointer un plugin précis ou une ferme à mobs mal conçue sans hypothèse hasardeuse.

Rapport timings (Paper/Spigot)

/timings on
# laisser tourner le monde 10 à 15 minutes
/timings paste

Le lien généré détaille le pourcentage de charge par plugin, par type d'entité et par monde, utile pour trancher entre une cause liée au gameplay et une cause liée au code.

Console et fichiers de logs

En parallèle du profilage, surveille la console live via le panel de gestion : les avertissements "Can't keep up" indiquent explicitement un tick qui a dépassé 50 ms, avec le nombre de millisecondes de retard accumulé.

Corriger les ralentissements et stabiliser le TPS serveur Minecraft

Une fois la cause identifiée, les corrections suivent une logique précise selon le diagnostic posé.

Réduire la charge de simulation du monde

• Baisser view-distance et simulation-distance dans server.properties
• Limiter le nombre de chunks pré-générés hors zone de jeu réelle
• Désactiver le random-tick-speed excessif sur les versions où il est réglable

Plafonner les entités et nettoyer les items

# paper-world-defaults.yml
entities:
  spawning:
    all-chunks-are-slime-chunks: false
  item-despawn-rate: 6000

Réduire le temps avant despawn des objets au sol et plafonner les caps de mobs (minecraft:cow, minecraft:zombie, etc.) limite drastiquement le travail du thread principal sans changer l'expérience de jeu perçue par les joueurs.

Utiliser une distribution orientée performance

Passer d'un moteur vanilla à une distribution comme Paper ou Purpur apporte des optimisations natives (async chunk loading, pathfinding optimisé) qui réduisent la charge CPU pour un même nombre de joueurs connectés, sans modifier les règles du jeu.

Redémarrer proprement après un pic de lag

systemctl status minecraft-server
systemctl restart minecraft-server

Un redémarrage planifié aux heures creuses, combiné à une sauvegarde automatique avant intervention, évite de perdre la progression du monde en cas de correction mal calibrée.

Allouer la bonne ressource matérielle

Au-delà de la configuration logicielle, le matériel sous-jacent reste déterminant : un processeur Ryzen à fréquence monocœur élevée associé à du stockage NVMe réduit le temps de lecture/écriture des chunks et des bases de données de plugins, ce qui se traduit directement par un MSPT plus bas. Retrouve l'ensemble des jeux pris en charge sur Tous nos serveurs de jeu, ou consulte d'autres guides techniques sur le Blog Fly-Serv.

Pour la documentation officielle sur le fonctionnement des ticks et du moteur de jeu, voir la Source.

Surveiller le TPS serveur Minecraft régulièrement, via les commandes natives ou un profilage spark, évite les mauvaises surprises en pleine session. La plupart des chutes viennent d'une accumulation d'entités, d'une distance de simulation trop large ou d'un plugin mal optimisé : des causes identifiables et corrigibles avec les bons outils.

FAQ

Pourquoi mon TPS chute-t-il uniquement quand plusieurs joueurs sont connectés ?

Chaque joueur charge sa propre zone de chunks selon la view-distance configurée. Plus il y a de joueurs dispersés, plus le nombre de chunks actifs augmente, ce qui alourdit chaque tick. Réduire la view-distance ou regrouper les zones de jeu limite cet effet.

Quelle est la différence entre TPS et MSPT ?

Le TPS indique le nombre de ticks exécutés par seconde, plafonné à 20. Le MSPT mesure le temps réel consommé par chaque tick en millisecondes. Un TPS à 20 avec un MSPT proche de 50 ms signale un serveur déjà saturé malgré une valeur apparemment correcte.

Les plugins ralentissent-ils toujours le TPS plus que le nombre de mobs ?

Non, cela dépend du cas. Un plugin mal codé avec des tâches synchrones peut peser plus lourd qu'une centaine de mobs bien optimisés. Un rapport spark ou timings permet de comparer objectivement le poids réel de chaque source avant d'agir.