Optimiser les performances d'un serveur de jeu : les leviers techniques

Les performances serveur de jeu ne dépendent presque jamais du nombre de cœurs affiché sur une fiche technique, mais d'un enchaînement de facteurs : fréquence mono-cœur, budget de tick, mémoire réellement utile, qualité du stockage et route réseau. Cet article détaille comment lire ces signaux, les mesurer avec de vrais outils, puis corriger ce qui freine réellement ta partie.

Comprendre les performances serveur de jeu : tick, TPS et mono-cœur

Un serveur de jeu fonctionne en boucle. À chaque itération, appelée tick, il recalcule les positions des entités, la physique, l'IA des mobs, les événements de blocs, les scripts de plugins ou de mods, puis envoie les paquets aux clients. Minecraft vise 20 ticks par seconde, soit 50 ms de budget par tick. Rust, ARK, Valheim ou Palworld ont leurs propres cadences, mais le principe reste identique : si le calcul dépasse le budget, le tick prend du retard.

Ce retard se traduit par du lag serveur : mobs qui glissent, coups qui ne s'enregistrent pas, machines qui ralentissent, portes qui s'ouvrent avec une seconde de délai. Rien à voir avec un ping élevé, et c'est la première distinction à faire avant toute optimisation. Pour un hébergeur Minecraft, cette différence conditionne tout le travail d'administration au quotidien.

Pourquoi la fréquence mono-cœur domine

La très grande majorité des moteurs de jeu multijoueur exécutent leur boucle principale sur un seul thread. Le monde, les entités et la logique de jeu sont calculés séquentiellement pour rester déterministes. Résultat : un processeur avec 32 cœurs modestes sera moins fluide qu'un Ryzen à haute fréquence avec moins de cœurs, parce que le tick ne se découpe pas.

Les cœurs supplémentaires restent utiles, mais pour des tâches périphériques : compression réseau, génération de chunks en arrière-plan (sur les forks modernes), sauvegardes, ramasse-miettes de la JVM, autres instances tournant sur la même machine. C'est pour cette raison qu'une machine hôte à fréquence élevée avec du SSD NVMe change concrètement le ressenti sur des jeux comme Serveur Rust ou Serveur ARK Survival Ascended, très gourmands en calcul d'entités.

Le rôle réel de la RAM

La RAM n'accélère rien. Elle évite un crash ou un ralentissement provoqué par une saturation. Deux erreurs classiques :

• Trop peu de mémoire : le moteur passe son temps à libérer de l'espace, les pauses de garbage collection allongent les ticks, les Out Of Memory tombent en pleine session.
• Trop de mémoire allouée : sur une JVM mal réglée, un tas énorme provoque des pauses de nettoyage plus longues. Allouer 24 Go à un serveur vanilla de 10 joueurs dégrade souvent la stabilité au lieu de l'améliorer.

La bonne approche consiste à mesurer l'utilisation réelle sur plusieurs jours, puis à laisser environ 20 à 30 % de marge au-dessus du pic observé.

Diagnostiquer avant d'optimiser : les outils qui parlent

Modifier une configuration sans mesure, c'est du bricolage. Voici l'ordre d'investigation que j'applique systématiquement.

1. Vérifier le TPS et le temps de tick

Sur un serveur Minecraft, la commande de base donne déjà une tendance :

/tps
# Sortie type (Paper) :
# TPS from last 1m, 5m, 15m: 19.98, 19.94, 18.72
# MSPT (Millisecond Per Tick): 12.4 / 47.9 (avg/max)

Le MSPT est plus parlant que le TPS. Un TPS à 20 avec un MSPT moyen de 45 ms signifie que tu es au bord du décrochage : le moindre pic (une explosion, un raid, un joueur qui explore) fera plonger la cadence. En dessous de 25 ms de moyenne, tu as de la marge.

2. Profiler pour identifier le coupable

Les profilers listent le coût réel de chaque tâche. Sur les forks Paper/Spigot :

# Timings intégrés
/timings on
# ... laisser tourner 10 à 15 minutes en charge réelle ...
/timings paste

# Profiler plus fin (plugin spark)
/spark profiler start --timeout 300
/spark profiler stop
/spark tps
/spark health

Le rapport isole en général un ou deux vrais responsables : un plugin de protection qui scanne trop de blocs, une ferme d'entités, une dimension entière chargée en permanence, un hook de base de données synchrone.

3. Regarder la machine, pas seulement le jeu

Depuis la console du panel Pterodactyl, tu vois déjà la consommation CPU et RAM de l'instance. Sur une machine que tu administres toi-même en SSH :

htop                 # charge par thread, repérer un cœur à 100 %
iostat -xz 2         # latence disque (await), saturation NVMe
free -h              # mémoire réelle et swap
journalctl -u minecraft -n 100 --no-pager
systemctl status minecraft

Un point critique : si swap est utilisé, les performances s'effondrent. Un serveur de jeu qui swappe n'est pas lent, il est inutilisable. Idem pour un await disque élevé, symptôme d'un stockage mécanique ou saturé — c'est exactement ce que le NVMe élimine sur les sauvegardes et le chargement de chunks.

4. Séparer lag serveur et lag réseau

Symptôme observé	Cause probable	Où chercher
Mobs saccadés, blocs qui repoussent, TPS bas	Tick dépassé (CPU / plugins / entités)	/tps, /spark, timings
Ping élevé mais monde fluide	Route réseau, distance géographique, Wi-Fi	ping, mtr, test filaire
Micro-freezes réguliers toutes les X minutes	Sauvegarde automatique, garbage collection	Config d'auto-save, flags JVM
Effondrement progressif en quelques heures	Fuite mémoire, accumulation d'entités	free -h, compteurs d'entités
Lenteur uniquement à la connexion de joueurs	Génération de terrain, view-distance	Paramètres de distance de vue

Les leviers d'optimisation qui changent vraiment le ressenti

Distance de vue et de simulation

C'est le réglage au plus fort impact, tous jeux confondus. Sur Minecraft, la distance de vue coûte de manière quadratique : passer de 12 à 8 chunks divise presque par deux le nombre de chunks à maintenir. La distance de simulation, elle, contrôle où les entités et les mécanismes continuent de tourner.

# server.properties
view-distance=8
simulation-distance=6
max-tick-time=60000
sync-chunk-writes=false
network-compression-threshold=256

Sur ARK, Rust ou Palworld, l'équivalent passe par les fichiers de configuration du jeu : densité de ressources, taux de reproduction, nombre maximal de créatures ou de structures par zone. Réduire un multiplicateur de spawn de 2,0 à 1,0 divise mécaniquement le travail de l'IA à chaque tick.

Maîtriser les entités

Les entités sont la première cause de chute de TPS sur les serveurs communautaires vivants. Fermes à mobs mal conçues, milliers d'items au sol, troupeaux de créatures apprivoisées, drones et véhicules abandonnés.

# bukkit.yml — limites de spawn par monde
spawn-limits:
  monsters: 40
  animals: 8
  water-animals: 3
  ambient: 1

# spigot.yml — fusion des items et XP
merge-radius:
  item: 3.5
  exp: 4.0
entity-activation-range:
  animals: 16
  monsters: 24
  misc: 8

Sur les jeux de survie type Serveur Valheim ou Serveur Palworld, la logique est la même : limiter le nombre de bases actives simultanément et purger régulièrement les structures inactives fait plus de bien qu'un ajout de mémoire.

Régler la JVM proprement (jeux Java)

Les flags de la machine virtuelle Java conditionnent la régularité du tick. Un jeu de paramètres éprouvé, avec un tas fixe (Xms = Xmx) pour éviter le redimensionnement :

java -Xms6G -Xmx6G \
  -XX:+UseG1GC \
  -XX:+ParallelRefProcEnabled \
  -XX:MaxGCPauseMillis=200 \
  -XX:+UnlockExperimentalVMOptions \
  -XX:+DisableExplicitGC \
  -XX:+AlwaysPreTouch \
  -XX:G1NewSizePercent=30 \
  -XX:G1MaxNewSizePercent=40 \
  -XX:G1HeapRegionSize=8M \
  -XX:G1ReservePercent=20 \
  -XX:InitiatingHeapOccupancyPercent=15 \
  -XX:SurvivorRatio=32 \
  -XX:MaxTenuringThreshold=1 \
  -jar paper.jar nogui

À vérifier aussi : la version de Java. Un runtime récent (Java 21 sur les versions modernes) apporte un ramasse-miettes nettement plus régulier que Java 8. Dans le panel Pterodactyl, ça se change en une ligne dans les variables de l'egg, sans toucher aux fichiers.

Trier les plugins et les mods

Un modpack de 250 mods n'est pas 250 fois plus lourd qu'un mod seul, mais deux ou trois d'entre eux consomment souvent 70 % du budget de tick. Méthode :

1. Profile en charge réelle, pas sur un serveur vide.
2. Classe les plugins par temps CPU cumulé dans le rapport.
3. Désactive le plus gourmand, relance, remesure sur la même durée.
4. Cherche une alternative plus légère ou réduis sa fréquence de scan dans sa config.

Les suspects habituels : plugins de logs de blocs en écriture synchrone, systèmes économiques interrogeant une base distante à chaque événement, générateurs de mini-cartes côté serveur, anti-cheat mal calibrés.

Sauvegardes et écritures disque

Une sauvegarde mal placée provoque des micro-freezes perçus comme du lag. Espace les auto-saves, évite les sauvegardes complètes en pleine soirée de jeu et appuie-toi sur les sauvegardes automatiques planifiées en heures creuses. Sur un stockage NVMe, l'opération reste courte ; sur un disque lent, elle bloque le tick le temps de l'écriture.

# Exemple de tâche planifiée côté système
0 5 * * * /usr/local/bin/backup-world.sh >> /var/log/backup.log 2>&1

# Sauvegarde propre : figer les écritures pendant la copie
screen -S mc -X stuff "save-off\n"
screen -S mc -X stuff "save-all flush\n"
tar -czf /backups/world-$(date +%F).tar.gz /srv/mc/world
screen -S mc -X stuff "save-on\n"

Latence réseau : l'autre moitié du ressenti

Un serveur à 20 TPS constants peut sembler injouable si le trajet réseau est mauvais. La latence n'est pas une question de puissance mais de distance, de qualité de peering et de stabilité de la liaison.

Mesurer correctement

# Latence brute et régularité
ping -c 50 ip.du.serveur

# Route complète, perte de paquets par saut
mtr -rwzbc 100 ip.du.serveur

# Vérifier qu'un port de jeu répond
nc -zv ip.du.serveur 25565

Lis surtout l'écart-type et la perte de paquets. Un ping moyen de 40 ms avec des pics à 300 ms donne un ressenti bien pire qu'un ping stable à 70 ms. Une perte de paquets supérieure à 1 % suffit à produire des rubber-bands en PvP.

Ce que tu peux réellement corriger

• Localisation : un serveur physiquement proche de la majorité de ta communauté reste le levier le plus efficace sur la latence.
• Côté joueur : câble Ethernet plutôt que Wi-Fi, arrêt des téléchargements en tâche de fond, désactivation du QoS agressif de la box.
• Compression réseau : sur Minecraft, un seuil de compression trop bas force la compression de petits paquets et consomme du CPU pour rien. 256 est une valeur saine.
• Protection volumétrique : une attaque DDoS se traduit d'abord par une latence erratique. Le filtrage anti-DDoS étant appliqué en amont côté infrastructure, tu n'as rien à configurer, mais garde le réflexe de vérifier la route avant de blâmer le jeu.

Hygiène d'administration qui protège les performances

Les incidents de sécurité dégradent les performances aussi sûrement qu'un mod mal codé : spam de connexions, bots de griefing, scripts injectés via une console RCON exposée.

• Mot de passe RCON long et unique, jamais réutilisé, jamais partagé en clair sur Discord.
• Whitelist pendant les phases de test et les événements sensibles.
• Sous-utilisateurs du panel avec permissions limitées pour ton staff, plutôt qu'un accès complet partagé.
• Mises à jour régulières du jeu, des plugins et des mods : une faille corrigée évite un abus qui saturera ton tick.
• Sauvegardes testées : une sauvegarde jamais restaurée n'est pas une sauvegarde.

Pour approfondir le fonctionnement du panel et de ses limites de ressources, la documentation officielle Pterodactyl détaille la gestion des allocations et des variables d'environnement. Tu trouveras d'autres guides d'administration par jeu sur le Blog Fly-Serv et la liste complète des jeux pris en charge sur Tous nos serveurs de jeu.

Checklist rapide de diagnostic

1. Le TPS est-il bas, ou seulement le ping ? (test /tps + mtr)
2. Un cœur est-il saturé alors que les autres dorment ? (htop)
3. La mémoire est-elle proche du plafond, y a-t-il du swap ? (free -h)
4. Le disque est-il en attente ? (iostat -xz)
5. Quel plugin ou mod domine le profil ? (/spark profiler)
6. Combien d'entités actives par monde, et où ?
7. Les distances de vue et de simulation sont-elles réalistes pour le nombre de joueurs ?
8. Les sauvegardes tombent-elles au pire moment ?

Applique-la dans cet ordre, en remesurant après chaque changement. Un seul paramètre modifié à la fois : c'est la seule façon de savoir ce qui a fonctionné.

Ce qu'il faut retenir sur les performances serveur de jeu

La fluidité se joue sur la fréquence mono-cœur, un budget de tick maîtrisé, une mémoire dimensionnée sans excès, du stockage rapide et une route réseau stable. Mesure d'abord avec /tps, un profiler et mtr, puis agis sur les distances de vue, les entités, les plugins et les sauvegardes. Une modification à la fois, toujours vérifiée par une nouvelle mesure.

FAQ

Mon TPS est à 20 mais mes joueurs se plaignent de lag : que vérifier ?

Le problème est réseau, pas serveur. Lance ping -c 50 et mtr -rwzbc 100 depuis un poste joueur pour repérer perte de paquets et pics de latence. Vérifie aussi le MSPT : un TPS à 20 avec un MSPT moyen supérieur à 40 ms indique des micro-décrochages invisibles dans la moyenne. Enfin, teste en Ethernet plutôt qu'en Wi-Fi.

Ajouter de la RAM améliore-t-il les performances d'un serveur de jeu ?

Seulement si la mémoire est réellement saturée. Au-delà du besoin réel, un tas trop grand allonge les pauses de garbage collection et dégrade la régularité du tick. Mesure le pic sur plusieurs jours avec free -h ou les graphiques du panel, garde 20 à 30 % de marge, et investis plutôt dans la fréquence CPU et un stockage NVMe.

Comment savoir quel mod ou plugin fait chuter mon TPS ?

Profile en charge réelle : /spark profiler start --timeout 300 puis stop, ou /timings on suivi de /timings paste après 10 à 15 minutes. Trie les résultats par temps CPU cumulé, désactive le premier de la liste, relance et remesure sur la même durée et le même nombre de joueurs. Un seul changement par test, sinon le résultat n'est pas interprétable.