Faire tourner un serveur Minecraft à 20 TPS

Un serveur Minecraft avance par ticks, vingt par seconde. Tant qu'il les tient, tout va bien. Dès qu'il retombe à quinze, le jeu ralentit : les blocs cassés reviennent, les mobs sautillent, et les joueurs partent.

Voici comment les tenir, dans l'ordre où cela se fait.

Mesurer avant de toucher à quoi que ce soit

Deux chiffres suffisent :

• Les TPS (ticks par seconde). Plafonnés à 20. En dessous de 19, le serveur est en retard.
• Le MSPT (millisecondes par tick). C'est le temps réellement passé à calculer un tick. Au-delà de 50 ms, les TPS commencent à tomber. C'est la mesure la plus utile des deux, parce qu'elle se dégrade avant que les TPS ne bougent.

Utilisez spark, intégré à Paper. /spark profiler enregistre quelques minutes d'activité et vous rend un rapport qui nomme le responsable, un plugin, une ferme, un morceau de monde. Régler un serveur sans profiler, c'est deviner : le guide Trouver la cause du lag avec Spark explique comment lire le rapport.

La distance de vue : le réglage qui compte

Dans server.properties :

• view-distance : combien de tronçons le joueur voit.
• simulation-distance : combien de tronçons le serveur calcule : mobs, cultures, redstone.

Le second coûte bien plus cher que le premier. Un réglage sain pour un serveur public : view-distance=8, simulation-distance=5. Personne ne remarque la différence en jeu ; le serveur, lui, la remarque tout de suite.

Descendre à 4 en distance de vue se voit, en revanche. C'est la limite à ne pas franchir sans raison.

Dompter les entités

Les entités sont la première cause de chute des TPS sur un serveur habité. Trois leviers, chacun dans son fichier :

• entity-activation-range, dans spigot.yml : le rayon à partir duquel une entité est réellement calculée. Réduire celui des monstres et des animaux ne change rien au jeu et allège beaucoup les fermes.
• Les limites d'apparition de mobs : spawn-limits dans bukkit.yml. Les valeurs par défaut sont généreuses.
• merge-radius, dans spigot.yml, pour les objets au sol et les boules d'expérience, regrouper les piles évite qu'un millier d'objets tombés traînent dans un coin.

Paper ajoute ses propres réglages dans config/paper-world-defaults.yml, comme les distances de disparition des monstres (despawn-ranges). La configuration anti-lag les donne tous, calibrés pour votre type de serveur.

Et surveillez les fermes. Une ferme à fer bien construite chez un joueur peut à elle seule coûter cinq millisecondes par tick.

Pré-générer le monde

Explorer, c'est générer du terrain, et générer du terrain est l'opération la plus coûteuse du jeu. Un joueur qui part en bateau vers l'inconnu fait ramer tout le monde.

Chunky règle le problème : il génère le monde à l'avance, tranquillement, pendant que personne ne joue. Générez un rayon de 5 000 blocs, puis posez une bordure de monde un peu à l'intérieur, avec /worldborder set 9800 : le guide Pré-générer son monde avec Chunky explique pourquoi.

Une bordure n'est pas une privation. Dix mille blocs de côté représentent cent millions de blocs de surface : aucune communauté n'en fait le tour.

Java : version et options

Prenez la version de Java que demande votre version du jeu : Java 21 de la 1.20.5 à la 1.21.x, Java 25 pour les versions 26.x. Leurs ramasse-miettes sont nettement meilleurs que ceux de Java 8 ou 11. La correspondance complète est dans Quelle version de Java pour son serveur.

Deux règles pour les options de lancement :

• -Xms et -Xmx à la même valeur. Laisser le tas grandir en cours de route provoque des à-coups.
• Ne donnez pas toute la mémoire de la machine. Le système en a besoin, et un tas trop grand allonge les pauses du ramasse-miettes au lieu de les éviter. 4 à 6 Go pour un serveur à plugins de trente joueurs, c'est confortable.

Les jeux d'options dits « Aikar » circulent depuis des années et restent un bon point de départ pour le ramasse-miettes G1. Mais ils ne compenseront jamais une ferme à mobs mal placée.

Ce qui ne sert à rien

• Ajouter de la mémoire quand le problème vient des entités. Le serveur ne va pas plus vite parce qu'il a plus de place.
• Ajouter des cœurs. Minecraft calcule son monde sur un seul fil. Un processeur à huit cœurs lents perd contre un processeur à quatre cœurs rapides. Quand un hébergeur met en avant le nombre de cœurs plutôt que la fréquence, méfiez-vous.
• Les plugins « d'optimisation » qui promettent tout. Ceux qui vident les entités périodiquement font disparaître les objets des joueurs, et on vous le reprochera.
• Changer dix réglages d'un coup. Vous ne saurez pas lequel a servi.

Le bon ordre

1. Profilez avec spark.
2. Réglez la distance de simulation et les portées d'activation des entités.
3. Pré-générez le monde et posez une bordure.
4. Traitez la ferme ou le plugin que spark a désigné.
5. Seulement ensuite, touchez aux options Java.

Neuf serveurs sur dix retrouvent leurs 20 TPS avant l'étape 4.

---

Un serveur fluide garde ses joueurs, et des joueurs qui restent votent. Référencez le vôtre, puis suivez sa disponibilité mesurée sur sa page de statut.