Comprendre la performance d'un serveur de jeu : TPS, RAM et mono-coeur

La performance serveur de jeu se juge d'abord à un chiffre : le TPS, ticks par seconde. Un monde qui rame, des joueurs qui téléportent, des coffres qui mettent trois secondes à s'ouvrir : dans la grande majorité des cas, le diagnostic commence par là, bien avant de blâmer le matériel.

Le TPS, indicateur numéro un de la performance serveur de jeu

Le TPS (ticks par seconde) mesure la vitesse à laquelle la boucle de jeu s'exécute. Sur un moteur Minecraft classique, la cible est fixée à 20 ticks par seconde, soit un tick toutes les 50 millisecondes. Chaque tick traite la physique, les entités, les blocs qui changent d'état, la logique redstone et, bien sûr, tout ce que font tourner les plugins. Dès que le calcul d'un tick dépasse 50 ms, le moteur ralentit la simulation pour rattraper le retard : c'est le fameux lag perçu par les joueurs, indépendamment de leur propre connexion.

Contrairement à une idée reçue, un TPS bas n'est presque jamais un problème de bande passante. C'est un problème de calcul : trop d'entités chargées, un chunk mal optimisé, une boucle de script mal écrite dans un plugin, ou simplement un processeur qui n'a pas la fréquence mono-cœur nécessaire pour boucler assez vite. Diagnostiquer la performance serveur de jeu commence donc toujours par lire ce chiffre avant de changer quoi que ce soit à la configuration.

Sur les moteurs orientés performance comme Paper ou Purpur, la commande suivante donne un relevé instantané :

/tps
/tps 1m 5m 15m

Un résultat proche de 20.0 sur les trois fenêtres indique une simulation saine. Un TPS qui chute uniquement sur la fenêtre 15 minutes pointe vers un pic ponctuel (chargement massif de chunks, raid, explosion de TNT en masse). Un TPS bas en continu, lui, trahit un goulot structurel : trop d'entités, redstone mal maîtrisée, ou configuration matérielle sous-dimensionnée. Si tu administres un monde Minecraft et que tu veux repartir sur une base propre pour tester ces réglages, la page hébergeur Minecraft de Fly-Serv détaille les caractéristiques matérielles disponibles pour ce type d'instance.

Lire le MSPT pour aller plus loin que le TPS

Le TPS plafonne à 20, ce qui masque les marges de manœuvre réelles. Le MSPT (millisecondes par tick) est plus parlant : il indique combien de temps chaque tick consomme réellement. Un MSPT moyen à 15 ms laisse de la marge avant d'atteindre les 50 ms fatidiques ; un MSPT à 45 ms signifie que le moteur est à la limite, même si le TPS affiche encore 20.0.

/tps
/mspt

Surveiller le MSPT permet d'anticiper un ralentissement avant qu'il ne devienne visible pour les joueurs, par exemple avant un événement communautaire qui va charger davantage d'entités et de chunks simultanément.

Pourquoi la performance mono-cœur du processeur change tout

La boucle de tick d'un moteur de jeu comme Minecraft, ARK ou Valheim est très majoritairement mono-threadée. Même sur un processeur à seize cœurs, c'est un seul cœur qui exécute la totalité de la logique de simulation à chaque tick. Ajouter des cœurs supplémentaires n'accélère donc pas la boucle principale : seule la fréquence réelle de ce cœur, et son IPC (instructions par cycle), détermine la vitesse de calcul.

C'est la raison pour laquelle un processeur Ryzen récent, avec une fréquence turbo élevée par cœur, apporte un gain direct et mesurable sur le TPS, là où un processeur orienté multi-cœur mais à fréquence plus basse peinera sur une simulation lourde en entités. Les tâches secondaires (compression des chunks, envoi réseau, certains calculs de pathfinding sur Paper) peuvent être déportées sur d'autres cœurs, mais le cœur de la logique de jeu reste contraint par la performance mono-cœur disponible.

Repérer un goulot CPU en pratique

Sous Linux, un coup d'œil à la charge CPU par processus donne une première indication :

top -H -p $(pgrep -f server.jar)
htop

Si un seul thread tourne constamment proche de 100 % pendant que les autres restent calmes, c'est le signe classique d'une boucle de tick saturée. Sur Paper et dérivés, l'outil spark fournit un profil détaillé directement dans le jeu :

/spark profiler start
/spark profiler stop
/spark tps

Le rapport généré classe les méthodes qui consomment le plus de temps CPU à chaque tick, souvent un plugin spécifique, une boucle de pathfinding d'entités hostiles, ou un système de scoreboard rafraîchi trop fréquemment.

ARK, Rust, Valheim : le même principe, des symptômes différents

Sur ARK, la saturation mono-cœur se traduit par des temps de sauvegarde interminables et des téléportations de créatures. Sur Rust, elle se manifeste par des décalages lors des raids ou des chutes de framerate côté joueur au moment des grosses explosions. Sur Valheim, c'est souvent la génération de zones qui rame en avançant en bateau. Dans tous les cas, le réflexe est identique : vérifier la charge mono-cœur avant d'incriminer la connexion réseau ou la configuration des joueurs.

RAM allouée : des besoins très différents selon le moteur

La RAM n'accélère pas un tick lent, mais son absence peut provoquer des pauses de garbage collection qui, elles, génèrent de vrais pics de lag. Le réglage dépend fortement du moteur utilisé.

Minecraft : attention au sur-allouement

Allouer trop de RAM à une instance Minecraft est une erreur fréquente. Une heap trop large pousse la JVM à accumuler davantage d'objets avant de déclencher un garbage collection, ce qui rend chaque passage de nettoyage plus long et donc plus visible en jeu. Les flags Aikar, largement utilisés sur les moteurs Paper, limitent justement ces pauses :

java -Xms6G -Xmx6G -XX:+UseG1GC -XX:+ParallelRefProcEnabled \
-XX:MaxGCPauseMillis=200 -XX:+UnlockExperimentalVMOptions \
-XX:+DisableExplicitGC -XX:+AlwaysPreTouch -jar server.jar nogui

Fixer Xms et Xmx à la même valeur évite les phases de redimensionnement dynamique de la heap, souvent responsables de micro-coupures.

ARK, Satisfactory, Rust : des moteurs gourmands en continu

Ces moteurs tournent sur Unreal ou un moteur propriétaire chargeant en permanence la carte entière en mémoire, bien au-delà des besoins d'une instance Minecraft classique. Un monde ARK avec plusieurs cartes actives ou un monde Rust avec une grande procédural map consomme la RAM de façon continue, sans pic de garbage collection comparable à la JVM : le symptôme d'un manque de RAM sur ces moteurs est plutôt un swap disque qui s'active, détectable via :

free -h
vmstat 1 5

Si le swap grimpe pendant les sessions actives, la RAM allouée est insuffisante pour la taille de la carte et le nombre de joueurs connectés.

Tableau comparatif rapide des symptômes

Moteur	Symptôme RAM insuffisante	Outil de diagnostic
Minecraft (Paper/Spigot)	Pics de lag réguliers (GC)	/timings report, spark
ARK Survival Evolved/Ascended	Swap disque, sauvegardes longues	free -h, vmstat
Rust	Chutes de TPS lors des raids	server.fps, console serveur
Valheim	Lenteur génération de zones	logs serveur, htop

Que tu administres une instance ARK, Rust ou Valheim, l'ensemble des jeux pris en charge figure sur la page Tous nos serveurs de jeu, utile pour comparer la configuration matérielle associée à chaque moteur avant de régler finement la RAM allouée.

Diagnostiquer les plugins et mods qui plombent les ticks

Une fois le TPS, le CPU mono-cœur et la RAM écartés comme cause principale, il reste souvent un coupable : un plugin ou un mod mal optimisé. C'est la cause la plus fréquente de dégradation progressive de la performance serveur de jeu au fil des mises à jour d'une communauté.

Timings et spark : isoler le plugin fautif

Sur les moteurs Paper, le rapport timings liste la consommation CPU de chaque plugin par tick :

/timings on
/timings report

Le rapport généré donne un pourcentage de temps de tick consommé par plugin. Un plugin de scoreboard dynamique, un système de protection de territoire mal codé, ou un plugin économique qui interroge la base de données à chaque tick ressortent immédiatement en tête de liste.

Les causes récurrentes côté configuration

• Vue de simulation trop large (view-distance et simulation-distance élevées sans matériel adapté)
• Pathfinding d'entités hostiles non limité dans les zones à forte densité de mobs
• Plugins de scoreboard ou de tablist rafraîchis à chaque tick au lieu d'un intervalle raisonnable
• Redstone en boucle fermée générant des mises à jour de bloc en continu
• Trop d'entités items au sol non nettoyées automatiquement

Un réglage simple dans server.properties ou paper-world-defaults.yml limite déjà une bonne partie de ces causes :

view-distance=8
simulation-distance=6
entity-tracking-range: 48

Suivre l'évolution dans le temps

Le diagnostic n'est pas un geste ponctuel : il vaut la peine de relever le TPS et le MSPT à intervalle régulier, surtout après l'ajout d'un nouveau plugin ou mod. Conserver un historique de ces relevés dans un fichier texte simple permet de repérer rapidement quelle mise à jour a fait chuter la performance serveur de jeu, bien plus efficacement qu'un diagnostic a posteriori quand les joueurs se plaignent déjà. Sauvegarder la configuration avant chaque changement, via le panel ou en copiant le dossier du monde, évite aussi de perdre une configuration stable en cas de régression.

Diagnostiquer une chute de performance serveur de jeu suit toujours le même ordre : lire le TPS et le MSPT, vérifier la charge mono-cœur, contrôler la RAM selon le moteur, puis isoler le plugin ou mod responsable. Cette méthode évite de changer du matériel inutilement quand le problème vient d'une configuration mal réglée.

FAQ

Pourquoi mon TPS chute-t-il uniquement pendant les raids ou les événements ?

Ces moments génèrent un pic ponctuel d'entités, d'explosions ou de calculs physiques simultanés. Vérifie le MSPT sur la fenêtre courte (1 minute) plutôt que la moyenne longue, et limite temporairement le nombre d'entités ou la portée de simulation pendant ces phases si le pic revient régulièrement.

Faut-il toujours allouer le maximum de RAM disponible à l'instance ?

Non, surtout sur un moteur basé Java comme Minecraft : une heap trop large allonge les pauses de garbage collection. Alloue une valeur cohérente avec le nombre de joueurs et de plugins réellement utilisés, puis ajuste en observant les pics de lag.

Comment savoir si le problème vient d'un plugin et pas du matériel ?

Lance un rapport timings ou un profil spark pendant une session active. Si un plugin précis consomme un pourcentage disproportionné du temps de tick par rapport aux autres, le problème est logiciel, pas matériel. Teste en le désactivant temporairement pour confirmer.