Comprendre ce qui rend un serveur de jeu performant

La performance serveur de jeu ne se résume jamais à une quantité de mémoire annoncée sur une fiche technique. Elle dépend d'un enchaînement de facteurs : fréquence du processeur, comportement mono-cœur du moteur, vitesse du stockage, qualité du filtrage réseau et discipline de configuration. Comprendre ces mécanismes permet de diagnostiquer une partie qui lague au lieu de rajouter de la RAM au hasard.

Les facteurs qui déterminent la performance serveur de jeu

La quasi-totalité des moteurs multijoueur populaires fonctionnent sur une boucle de simulation principale exécutée sur un seul thread. Minecraft (Java), Rust, ARK, Valheim, Project Zomboid ou Palworld calculent la physique, l'IA, les entités et la logique de monde dans cette boucle unique. Résultat : un processeur à 16 cœurs lents sera systématiquement battu par un processeur à haute fréquence pour faire tourner une partie fluide. C'est la raison pour laquelle les architectures Ryzen haute fréquence sont privilégiées côté infrastructure de jeu, et pourquoi une machine « puissante sur le papier » peut décevoir en pratique.

Sur des jeux comme Minecraft, la mécanique est particulièrement lisible : chaque tick doit tenir dans 50 ms. Si tu veux comparer les caractéristiques matérielles retenues pour ce type de moteur, la page hébergeur Minecraft détaille la configuration utilisée chez Fly-Serv. Pour le reste de cet article, on reste sur la mécanique technique : comment mesurer, comment diagnostiquer, comment corriger.

Mono-cœur : le facteur le plus sous-estimé

Un serveur de jeu ne « répartit » pas sa charge comme un serveur web. Les cœurs supplémentaires servent surtout aux tâches annexes : compression des sauvegardes, génération de chunks en arrière-plan sur certains forks, réseau, pathfinding déporté quand le moteur le permet. Mais dès qu'une horde de zombies spawn, qu'une base de 40 000 entités est chargée ou qu'un joueur explore une zone non générée, tout retombe sur le thread principal.

• Fréquence élevée + IPC moderne : gain direct sur le temps de tick.
• CPU dédié vs partagé : un cœur partagé subit le bruit des voisins, ce qui produit des micro-freezes irréguliers difficiles à diagnostiquer.
• Steal time : sur une machine virtualisée, un steal visible dans top signale que le CPU n'est pas réellement disponible.

# Vérifier la charge et le steal time sur une machine Linux
top -bn1 | head -n 5
# %Cpu(s):  35.2 us,  4.1 sy,  0.0 ni, 60.1 id,  0.0 wa,  0.0 hi,  0.6 si,  0.0 st
#                                                                              ^^^ st doit rester à 0.0

RAM : suffisante, pas surdimensionnée

La mémoire n'accélère rien. Elle empêche seulement de ralentir. Trop peu de RAM provoque du swap, des garbage collections agressives (sur les moteurs Java) et des crashs OutOfMemoryError. Trop de RAM allouée à une JVM peut au contraire allonger les pauses du ramasse-miettes si les paramètres ne sont pas adaptés.

Jeu	Mémoire de travail typique	Facteur principal de charge
Minecraft vanilla / Paper	2 à 6 Go	Entités, chunks chargés, view-distance
Minecraft modé (100+ mods)	8 à 12 Go	Tick des machines, chunkloaders
Rust	8 à 16 Go	Taille de map, nombre d'entités construites
ARK Survival Ascended	12 à 16 Go	Structures, dinos apprivoisés, mods
Valheim	4 à 6 Go	Zones actives, portails, bases proches
Palworld	8 à 16 Go	Pals actifs, bases automatisées
Project Zomboid	4 à 8 Go	Zombies simulés, taille de la carte explorée

Sur une instance Java, fixe -Xms et -Xmx à la même valeur pour éviter les redimensionnements de heap en pleine partie :

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

Stockage NVMe : là où ça se voit vraiment

Le stockage intervient à des moments précis mais très visibles : chargement du monde au démarrage, écriture des régions, sauvegarde automatique, génération de terrain. Sur un disque lent, une sauvegarde de monde ARK ou Rust bloque le thread principal quelques secondes, et tous les joueurs ressentent un freeze simultané. En NVMe, la même opération passe souvent sous le seuil perceptible. C'est le cas typique où le matériel change l'expérience de jeu sans changer une seule ligne de configuration.

# Repérer une saturation disque pendant une sauvegarde
iostat -xz 2 5
# Une colonne %util proche de 100 avec un await élevé = goulot d'étranglement I/O

TPS, tick rate et latence : mesurer avant de corriger

Un joueur qui dit « ça lag » décrit trois symptômes très différents. Séparer les mesures est la première étape de tout diagnostic sérieux.

TPS et MSPT

Le TPS (ticks par seconde) est la cadence de la simulation. Sur Minecraft, la cible est 20 TPS, soit 50 ms par tick maximum. Le MSPT (millisecondes par tick) est plus utile : un TPS affiché à 20 avec un MSPT à 48 ms signifie que tu es à la limite et que le prochain raid en fera basculer le serveur.

# Dans la console du panel Pterodactyl (Paper / Spigot)
tps
mspt

# Profilage précis avec le plugin Spark
spark profiler start --timeout 120
spark profiler stop
spark tps

Sur Rust, la commande console server.fps et global.status donnent l'équivalent. Sur ARK, on surveille plutôt le temps de sauvegarde et le nombre de structures. Sur Project Zomboid, la charge dépend du nombre de zombies effectivement simulés autour des joueurs connectés.

Latence réseau

La latence n'a rien à voir avec le TPS. Un serveur à 20 TPS parfaits peut donner une sensation de caoutchouc si le trajet réseau est mauvais. Teste la route, pas seulement le ping moyen :

# Depuis ta machine, vers l'IP du serveur
ping -c 20 51.xx.xx.xx
mtr -rwzbc 50 51.xx.xx.xx   # Linux
# Windows : tracert 51.xx.xx.xx

Ce qui compte pour un jeu compétitif, c'est la stabilité : un ping constant à 45 ms est plus confortable qu'un ping oscillant entre 20 et 90 ms. Le jitter et la perte de paquets se voient dans la colonne Loss% de mtr. Un choix de localisation cohérent avec ta communauté (France ou Europe de l'Ouest pour un public francophone) réduit mécaniquement le RTT.

Le troisième symptôme : le client

Beaucoup de plaintes de « lag » sont en réalité des chutes de FPS côté client, aggravées par des shaders, un pack de textures 512x ou un modpack lourd. Avant de toucher à la configuration, demande une capture du F3 (Minecraft) ou du compteur de FPS : si le TPS est à 20 et la latence à 30 ms, le problème n'est pas sur le serveur.

Mods, plugins et configuration : là où fuit la performance

Dans la pratique, la majorité des pertes de performance serveur de jeu ne viennent pas du matériel mais des réglages et des extensions installées. Un moteur bien configuré sur un CPU correct tient plus de joueurs qu'un moteur mal réglé sur du matériel haut de gamme.

Les réglages qui coûtent le plus cher

• Distance de vue / de simulation : sur Minecraft, passer view-distance de 10 à 6 et simulation-distance à 4 divise fortement la charge par joueur.
• Taux de spawn : sur ARK ou Palworld, multiplier les créatures augmente linéairement le coût de l'IA.
• Nombre d'entités par zone : les fermes à mobs, les tas d'items non ramassés et les bases surchargées de structures sont les premiers coupables.
• Autosave trop fréquent : une sauvegarde toutes les 5 minutes sur un gros monde crée un micro-freeze périodique. Espace-la et appuie-toi sur les sauvegardes automatiques de l'infrastructure.
• Tick rate réseau : sur Rust, augmenter le tickrate améliore la sensation de tir mais consomme du CPU et de la bande passante.

# Extrait de server.properties (Minecraft)
view-distance=7
simulation-distance=5
max-tick-time=60000
network-compression-threshold=256
sync-chunk-writes=false

# Extrait de configuration Rust (server.cfg)
server.maxplayers 100
server.tickrate 30
server.saveinterval 600
decay.upkeep true

Auditer ses plugins et mods

Un seul plugin mal écrit peut consommer 15 ms par tick. La méthode est toujours la même : profiler, isoler, retirer. Sur les serveurs Bukkit/Paper, timings ou Spark identifient précisément la classe fautive. Sur les moteurs sans profileur intégré, la méthode par dichotomie reste valable : désactive la moitié des mods, mesure, recommence.

1. Sauvegarde le monde avant toute manipulation depuis le panel.
2. Lance un profilage sur une période de charge réelle, pas sur un serveur vide.
3. Note le MSPT de référence.
4. Retire ou reconfigure un élément à la fois.
5. Compare sur la même durée et le même nombre de joueurs.

La documentation officielle de Source détaille chaque paramètre de paper-world-defaults.yml, y compris ceux qui touchent au comportement des entités et à la génération de chunks. C'est la référence à lire avant de copier une configuration trouvée sur un forum.

Le panel comme outil de diagnostic

Un panel Pterodactyl ne sert pas seulement à démarrer et arrêter. La console live, les graphiques de consommation CPU/RAM et le gestionnaire de fichiers permettent de corréler un pic de charge avec un événement de jeu. Si la RAM plafonne en permanence à 98 %, ce n'est pas un mystère : le heap est trop petit ou une fuite mémoire est en cours. Si le CPU d'un seul thread sature alors que les autres dorment, tu es sur une limite mono-cœur, pas sur un manque de mémoire. Tu retrouveras ce type d'outillage sur l'ensemble des jeux proposés, du Serveur Rust au Serveur ARK Survival Ascended en passant par le Serveur Valheim.

Stabilité : anti-DDoS, sauvegardes et routine d'exploitation

Un serveur rapide mais instable est inutilisable. La stabilité repose sur trois piliers : protection réseau, restauration possible, et discipline de mise à jour.

Filtrage réseau

Les attaques volumétriques visent régulièrement les communautés de jeu, notamment sur Rust, FiveM et Minecraft en période de wipe ou d'événement. Un filtrage anti-DDoS en amont de l'infrastructure absorbe le trafic avant qu'il n'atteigne la machine. C'est inclus par défaut côté Tous nos serveurs de jeu, ce qui évite d'avoir à bricoler des règles de rate limiting locales pour du volumétrique. En revanche, ce qui reste à ta charge, c'est la couche applicative :

• RCON : mot de passe long et aléatoire, jamais réutilisé, jamais partagé dans un Discord public.
• Whitelist ou système de queue prioritaire pour limiter les connexions parasites.
• Sous-utilisateurs du panel plutôt qu'un accès unique partagé entre modérateurs.
• Journalisation : garder les logs de connexion pour identifier les comportements anormaux.

Sur une machine Linux administrée par toi-même, les bases restent valables :

# Clés SSH plutôt que mot de passe
ssh-keygen -t ed25519 -C "admin-gameserver"
ssh-copy-id -i ~/.ssh/id_ed25519.pub user@ip

# Pare-feu minimal
ufw default deny incoming
ufw allow 22/tcp
ufw allow 28015/udp        # exemple Rust
ufw enable

# Protection contre le bruteforce SSH
apt install fail2ban -y
systemctl enable --now fail2ban

Sauvegardes : la seule assurance réelle

Un monde corrompu par un crash pendant l'écriture, un plugin qui efface des inventaires, un admin qui teste une commande mal comprise : les incidents sont fréquents. Les sauvegardes automatiques limitent la perte à quelques minutes de jeu. Deux règles simples : vérifie qu'une restauration fonctionne avant d'en avoir besoin, et conserve au moins une copie hors du serveur actif avant une opération risquée (montée de version, ajout d'un gros modpack, changement de map).

Mises à jour et fenêtres de maintenance

Les correctifs de moteur apportent régulièrement des gains de performance et des correctifs de sécurité. Mais une mise à jour non testée casse souvent les mods. Le schéma qui fonctionne :

1. Annonce une fenêtre de maintenance à ta communauté.
2. Sauvegarde complète depuis le panel.
3. Mets à jour le moteur, puis les mods, en vérifiant les versions compatibles.
4. Démarre en console et lis les logs jusqu'au message de fin de chargement.
5. Teste 10 minutes en solo avant de rouvrir les connexions.

D'autres guides pratiques par jeu sont regroupés sur le Blog Fly-Serv, notamment sur les configurations spécifiques à Palworld, Enshrouded ou Project Zomboid.

Synthèse : une méthode de diagnostic en cinq points

Symptôme	Mesure à faire	Cause probable
Freeze périodique régulier	Intervalle des autosaves, iostat	Sauvegarde bloquante / stockage lent
TPS bas en permanence	mspt, profileur	Charge mono-cœur, mod ou entités excessives
Ping élevé mais TPS à 20	mtr, jitter	Route réseau ou connexion du joueur
Crash aléatoire	Logs, OutOfMemoryError	Heap insuffisant ou fuite mémoire
Dégradation progressive	Nombre d'entités, taille du monde	Accumulation d'items, structures, chunks

Mesure d'abord, modifie ensuite, une variable à la fois. C'est la seule approche qui permet de savoir ce qui a réellement amélioré la situation.

La performance serveur de jeu tient donc à un équilibre : un CPU rapide en mono-cœur, une mémoire calibrée, du NVMe pour absorber les écritures, un filtrage réseau en amont et une configuration nettoyée de ses excès. Aucun de ces éléments ne compense l'absence des autres.

À retenir

La fluidité d'une partie multijoueur se joue sur des détails mesurables : temps de tick, jitter réseau, temps d'écriture disque, nombre d'entités simulées. Prends l'habitude de relever ces valeurs quand tout va bien, pour disposer d'une référence le jour où ça dérape. Un administrateur qui connaît ses chiffres corrige en quelques minutes ce qu'un autre cherche pendant des semaines.

FAQ

Pourquoi ajouter de la RAM ne corrige-t-il pas toujours un TPS bas ?

Parce que le TPS dépend du temps de calcul de la boucle de simulation, exécutée sur un seul thread. Si le MSPT dépasse 50 ms à cause de milliers d'entités, d'un mod gourmand ou d'une distance de simulation trop élevée, la mémoire n'y change rien. Profile d'abord avec Spark ou timings, puis réduis la charge réelle. La RAM ne devient le problème que si tu observes du swap, une saturation du heap ou des erreurs OutOfMemoryError dans les logs.

Comment savoir si le lag vient du réseau ou du serveur ?

Compare deux indicateurs indépendants. Relève le TPS/MSPT dans la console du panel : s'ils sont bons, la simulation tourne correctement. Lance ensuite un mtr ou un ping long vers l'IP : un jitter important ou de la perte de paquets sur un saut intermédiaire indique un problème de route. Si les deux sont sains, regarde le FPS côté client, souvent plombé par des shaders ou un modpack lourd.

À quelle fréquence faut-il déclencher une sauvegarde sans dégrader la fluidité ?

Sur un monde volumineux, une sauvegarde toutes les 5 minutes provoque des micro-freezes visibles. Un intervalle de 10 à 20 minutes est un bon compromis pour la plupart des jeux de survie, complété par une sauvegarde manuelle avant toute opération sensible. Sur stockage NVMe, l'écriture est nettement plus courte, ce qui rend l'opération quasi imperceptible. Vérifie toujours qu'une restauration fonctionne avant d'en avoir réellement besoin.