Optimiser la config Paper : les réglages qui améliorent vraiment les performances

Pas une semaine ne passe sans que quelqu'un, quelque part sur un Discord, partage une « config Paper optimisée » censée rendre votre serveur « deux fois plus rapide ». La réalité : les réglages par défaut de Paper sont déjà très corrects, l'essentiel du gain tient dans une poignée de boutons, et le reste d'une telle config magique change surtout la façon dont votre serveur se joue — pas sa vitesse. D'où cet article : quels réglages apportent vraiment des performances, dans quel fichier ils habitent, et pourquoi il faut mesurer avant de toucher à quoi que ce soit.

Mesurer d'abord, régler ensuite

Régler sans mesurer, c'est jouer aux devinettes. Heureusement, mesurer est devenu facile : les versions récentes de Paper embarquent le profiler spark par défaut. Avec /spark tps, vous voyez TPS et MSPT d'un coup d'œil, et avec /spark profiler, vous lancez une mesure qui montre où part le temps : entités, hoppers, génération du monde ou ce fameux plugin. Les anciens rapports timings sont en voie de disparition ; spark est le successeur.

Distinction importante : des FPS bas chez un joueur, c'est du lag client, et aucune config serveur n'y changera rien. Ce n'est que lorsque le TPS descend sous 20 ou que le MSPT rampe durablement vers 50 que votre serveur souffre vraiment. Mesurez par ailleurs à un moment représentatif — une soirée chargée, pas un mardi matin désert — et conservez cette mesure. C'est la seule façon de voir, après un changement, s'il a vraiment servi à quelque chose.

Les couches de configuration en un coup d'œil

Paper s'appuie sur Spigot, qui s'appuie lui-même sur Bukkit et vanilla. Chaque couche a son propre fichier :

Bon à savoir : les réglages de paper-world-defaults.yml peuvent être remplacés par monde avec le fichier paper-world.yml dans le dossier du monde concerné.

Les boutons qui font vraiment quelque chose

view-distance et simulation-distance

Le plus grand levier, tous deux dans server.properties. View-distance détermine combien de chunks un joueur voit ; simulation-distance détermine dans combien de chunks le monde vit réellement : les mobs bougent, les cultures poussent, les machines tournent. Simuler coûte bien plus cher qu'afficher. D'où l'astuce classique : garder une view-distance généreuse (8 à 10) et baisser la simulation-distance (5 à 7 sur un serveur chargé). Les joueurs voient un horizon lointain, tandis que votre serveur ne doit faire tourner qu'une fraction de ces chunks. La marche à suivre pour la view-distance est dans la base de connaissances : modifier la view-distance.

Les spawns de mobs

Les spawn-limits dans bukkit.yml déterminent combien de mobs par catégorie peuvent exister autour des joueurs ; les monstres sont à 70 par défaut. Sur un serveur chargé, vous pouvez descendre progressivement. Dans spigot.yml, mob-spawn-range doit rester en équilibre avec votre simulation-distance, et Paper répartit par défaut les spawns équitablement entre les joueurs, pour qu'un joueur AFK près d'une ferme n'avale pas tous les spawns. Attention toutefois : couper trop agressivement se ressent immédiatement dans le jeu — nuits vides, fermes à l'arrêt, joueurs mécontents. Par petites étapes, donc.

Les hoppers

Les grands systèmes de tri et les fermes à milliers de hoppers peuvent peser sérieusement sur votre temps de tick. Dans spigot.yml, ticks-per.hopper-transfer et ticks-per.hopper-check déterminent la fréquence de travail des hoppers ; les augmenter un peu fait alors une différence sensible, mais modifie le timing des fermes et machines de tri existantes. Dans paper-world-defaults.yml, vous pouvez en plus accorder du repos aux hoppers pleins avec cooldown-when-full. Mesurez d'abord si les hoppers sont seulement votre problème avant de toucher quoi que ce soit ici.

Le chargement des chunks

Générer de nouveaux chunks est l'une des tâches les plus lourdes qu'un serveur connaisse. Paper propose dans paper-global.yml des boutons pour le système de chunks, mais le conseil honnête est : n'y touchez pas, sauf si une mesure vous y conduit et que vous savez ce que vous faites — les valeurs par défaut sont bien choisies. Vous gagnerez davantage avec une bordure de monde et la prégénération des chunks (voir « À lire aussi »), et avec un stockage rapide : charger les chunks depuis du NVMe, cela se sent tout simplement en jeu.

Des valeurs saines par type de serveur

Petit serveur survival (2 à 10 joueurs) : laissez presque tout par défaut. Les valeurs par défaut de Paper sont largement dimensionnées pour cela ; si ça accroche quand même, c'est plus probablement une ferme extrême, un plugin lourd ou un manque de RAM que votre config. Passer des heures en tuning est ici rarement rentable.

Serveur communautaire chargé (20+ joueurs) : prenez ceci comme point de départ, pas comme dogme :

• view-distance 8 et simulation-distance 6 ;
• spawn-limits.monsters en baisse progressive depuis 70 ;
• mob-spawn-range aligné sur votre simulation-distance ;
• les réglages des hoppers uniquement si spark pointe vers les hoppers.

Appliquez les changements un par un et mesurez au moins une soirée chargée après chaque étape. Sinon, vous ne saurez jamais quel bouton a fait la différence — ni lequel a cassé quelque chose.

Méfiez-vous des « configs magiques » d'internet

Au sujet de ces configs d'optimisation toutes faites qui circulent partout : usez-en avec parcimonie. Elles sont souvent écrites pour d'anciennes versions, basculent des dizaines de réglages d'un coup et suppriment surtout du comportement : moins de spawns de mobs, un autre timing redstone, des fermes qui cessent de fonctionner en silence. Si votre serveur accélère, vous ne savez pas grâce à laquelle des quarante lignes ; si quelque chose casse, pas davantage. Si vous voulez tout de même en utiliser une : posez-la à côté des valeurs par défaut, n'adoptez consciemment que ce que vous comprenez et avancez par petites étapes. Les valeurs par défaut de Paper ont été écrites par les gens qui développent eux-mêmes le logiciel serveur ; « tout changer » est rarement un progrès.

Quand le tuning ne suffit pas

Pour finir, parlons franchement : une config ne fabrique pas de matériel. Trop peu de RAM pour votre nombre de joueurs, une pile de plugins lourds ou un stockage lent, cela ne se règle pas en YAML. Si spark pointe vers une pression mémoire ou un stockage de chunks trop lent, une formule plus grande est tout simplement le meilleur investissement. Chez MC-Node, chaque serveur Minecraft tourne sur notre propre matériel avec stockage NVMe — une différence sensible justement pour les chunks — à partir de 0,50 € par mois, comptez environ 1,10 € par Go de RAM. Tout est résiliable chaque mois : essayer une taille au-dessus et redescendre si c'était exagéré ne pose donc aucun problème.

À lire aussi

• Paper, Spigot, Purpur ou vanilla : quel logiciel serveur choisir ?
• TPS, MSPT et lag : ce que les chiffres veulent vraiment dire
• spark : trouver d'où vient le lag sur votre serveur Minecraft
• Prégénérer les chunks pour un serveur Minecraft plus fluide