Guide de Performance Plugins (Spigot/Paper/Purpur, etc)

Bonjour !
Les performances d’un serveur Minecraft dépendent fortement de sa configuration logicielle et matérielle. Ce guide s’adresse aux administrateurs (semi-)expérimentés utilisant Spigot, Paper ou des forks similaires (Purpur, Pufferfish…), et couvre les versions récentes 1.20.x à 1.21.x (avec des notes pour les versions antérieures le cas échéant). Nous allons expliquer les réglages critiques des fichiers de configuration (spigot.yml, paper.yml, bukkit.yml, purpur.yml, etc.), pourquoi les valeurs par défaut sont souvent sous-optimales, et comment des ajustements améliorent le TPS, la charge CPU et la stabilité du serveur. Nous donnerons également des recommandations de plugins utiles pour les performances, comparerons rapidement les avantages de Purpur/Pufferfish face à Paper/Spigot, et fournirons des conseils sur la configuration Java (versions, flags JVM G1GC, etc.). Le tout est organisé par sections pour une lecture claire et rapide.

Choisir Spigot, Paper ou un fork optimisé ?

Préférez Paper ou ses forks à Spigot. Spigot (et son prédécesseur CraftBukkit) est la base historique, mais il est aujourd’hui en retrait en termes de performance par rapport à Paper et consorts. Paper est un fork de Spigot apportant de nombreuses optimisations et correctifs tout en restant compatible avec les plugins Spigot/Bukkit. Paper expose également des dizaines d’options de configuration avancées pour peaufiner les performances sans altérer significativement le gameplay.

Purpur est un fork de Paper orienté vers la personnalisation poussée. Techniquement, Purpur inclut toutes les optimisations de Pufferfish (un autre fork, voir ci-dessous) mais n’ajoute pas de gain de performance supplémentaire propre. En revanche, il offre des centaines de nouvelles options de configuration “exotiques” pour ajuster les mécanismes de jeu (ex : activer la possibilité de monter certains mobs, autoriser les calamars volants, configurer le sommeil d’un seul joueur, etc.). Par défaut, ces fonctionnalités supplémentaires de Purpur sont désactivées, le serveur se comportant alors comme un Paper/Pufferfish standard. N’utilisez Purpur que si vous avez besoin de ces options de gameplay supplémentaires, car qui dit plus de patchs dit potentiellement plus de bugs ; si vous n’en avez pas l’usage, mieux vaut s’en tenir à Pufferfish ou Paper pour une stabilité maximale.

Pufferfish est un fork de Paper axé sur la performance pure, apparu en 2021. Il intègre de nombreux patchs avancés tout en restant compatible avec l’API Paper. Ses améliorations incluent par exemple : traitement partiellement asynchrone de certaines entités, algorithmes d’IA de mob plus rapides (système DAB), rendu des cartes optimisé via SIMD, gestion des hoppers plus efficiente, optimisation du ray tracing (lignes de vue), meilleur usage mémoire pour réduire les pauses GC, etc. La plupart de ces optimisations sont transparentes pour le gameplay (et celles qui pourraient l’impacter sont désactivables dans pufferfish.yml si besoin). En complément, Pufferfish propose des fonctions “entreprise” utiles aux administrateurs, par exemple l’intégration de Sentry.io pour remonter automatiquement les erreurs serveur, et un profiler intégré (Flare) capable d’analyses avancées (y compris du profilage mémoire). En somme, Pufferfish vise la performance maximale tout en s’éloignant le moins possible du comportement vanilla. Si votre objectif est de supporter un grand nombre de joueurs avec une charge élevée, Pufferfish sera souvent le meilleur choix pour gratter des pourcentages de TPS en plus. (Note : Il existe même un Pufferfish+, version encore plus optimisée incluant un suivi d’entités et un pathfinding entièrement asynchrones, mais il s’agit d’un produit commercial à destination des très gros serveurs.)

En résumé : Pour la majorité des serveurs, Paper offre déjà un excellent compromis entre performance et fidélité au gameplay vanilla. Purpur peut être envisagé si vous souhaitez une grande liberté de configuration et quelques fonctionnalités inédites, mais sans gain de TPS par rapport à Pufferfish. Pufferfish apporte un surcroît de performance et de stabilité appréciable sur les serveurs très peuplés ou exigeants, sans modification notable de gameplay. Évitez en revanche les JAR “maison” obscurs ou payants promettant des miracles asynchrones – il y a 99% de chances que ce soit inefficace voire nuisible. De même, évitez de rester sur un serveur Vanilla pur ou même Spigot si vous pouvez passer sur Paper : vous bénéficieriez d’un écart de performance notable rien qu’avec le changement de software.

Paramètres critiques dans les fichiers de configuration

Avant d’entrer dans le détail, notez qu’aucun réglage universel ne garantit 20 TPS constants en toutes circonstances. Chaque serveur a ses particularités (taille du monde, nombre de joueurs, type de jeu, fermes construites, etc.). Les valeurs suggérées ici sont des points de départ recommandés (“good starting value”) issus de l’expérience collective, qu’il faudra ajuster selon vos besoins. L’optimisation consiste souvent à faire des compromis : diminuer certaines distances, fréquences ou quantités pour soulager le CPU, au prix de légers changements côté gameplay. À vous de trouver le juste équilibre entre performances et expérience de jeu.

Nous allons parcourir fichier par fichier les options essentielles à optimiser, en justifiant l’impact de chaque modification. Les sections suivantes couvrent successivement bukkit.yml, spigot.yml, paper.yml (configuration Paper/Pufferfish globale et par monde), puis purpur.yml (options spécifiques aux forks comme Purpur). Enfin, nous aborderons aussi quelques réglages hors config (JVM, OS).

bukkit.yml – Limites et fréquences de spawn des mobs

Le fichier bukkit.yml gère notamment les paramètres de spawn des entités passives et hostiles. Les valeurs par défaut de Bukkit/Spigot sont souvent calibrées large, convenant à de petits serveurs peu peuplés, mais excessives pour un serveur survie avec de nombreux joueurs. Deux catégories d’options à ajuster :

• spawn-limits : Ce sont les quotas de mobs pouvant spawner par joueur. Par défaut, un joueur peut avoir jusqu’à ~70 monstres, 10 animaux, 15 créatures aquatiques, etc. autour de lui, ce qui avec plusieurs joueurs peut vite saturer le serveur en entités. Il est recommandé de réduire ces limites. Par exemple, des valeurs de départ raisonnables sont autour de 20 monstres, 5 animaux, 2 créatures aquatiques, 1 créature ambiante par joueur. Le calcul interne multiplie ces limites par le nombre de joueurs connectés, donc même avec plusieurs joueurs, le total global reste proportionné. En baissant ces chiffres, vous diminuez la densité de mobs à gérer, allégeant la charge serveur. Attention toutefois : cela réduit d’autant la faune et le difficulté du jeu. Si votre serveur mise sur la survie “hardcore” ou les fermes à mobs massives, ne descendez pas trop bas sous peine de frustrer les joueurs. Trouvez un compromis (ex : ~30 monstres si vous voulez un peu plus d’action). Pour compenser la baisse, on peut aussi jouer sur le rayon de spawn, voir plus bas.

• ticks-per: sections de spawn : Ces réglages contrôlent la fréquence à laquelle le serveur tente de faire spawn de nouvelles entités. Par défaut, Minecraft essaye de faire spawn des monstres à chaque tick (20 fois par seconde) et des animaux toutes les 400 ticks (~20 secondes). Vous pouvez ralentir légèrement ces tentatives sans impact visible sur le jeu, surtout pour les entités moins cruciales. Par exemple, mettre monster-spawns à 2 (au lieu de 1) signifie n’essayer qu’une fois toutes les 2 ticks – la différence de taux d’apparition est imperceptible pour les joueurs, mais le serveur traite deux fois moins de cycles de spawn de monstres. Le guide Paper suggère même monster-spawns: 10 ticks, ce qui reste fluide dans la plupart des cas. Pour les catégories d’animaux et créatures aquatiques, qui ne sont pas constamment tués en jeu, vous pouvez augmenter radicalement les intervalles – par exemple 400 ticks (20 secondes) ou plus. Ainsi, le serveur évite de scanner inutilement à chaque tick pour des poulpes ou chauves-souris qui de toute façon atteignent vite le plafond de population.
  
  En résumé : augmentez ticks-per.*-spawns (quelques centaines pour la faune aquatique/ambiante, 2 à 10 pour les monstres) afin d’espacer les tentatives de spawn et économiser du temps CPU. L’impact sur le gameplay est minime tant que les limites de population (ci-dessus) restent cohérentes.

En ajustant spawn-limits et ticks-per-spawns conjointement, on peut réduire drastiquement le nombre total de mobs actifs à gérer tout en préservant une expérience convenable pour chaque joueur. Notez que Paper offre une option très utile, per-player-mob-spawns (dans paper.yml), qui répartit mieux les spawns entre joueurs plutôt que de remplir le quota d’un seul joueur avant de passer au suivant. En activant cette option (voir section Paper plus loin), vous pourrez vous permettre des limites plus basses sans priver les joueurs de rencontres : chaque joueur aura sa part équitable de mobs autour de lui. Ce réglage a un très léger coût CPU, mais son bénéfice sur la stabilité des populations l’emporte largement sur ce surcoût.

spigot.yml – Distances de vue, activation et suivi des entités, gestion des items

Le fichier spigot.yml (utilisé par Spigot, Paper et forks) contient plusieurs paramètres clés pour contrôler la portée d’activité des entités et la gestion des objets au sol. Les valeurs par défaut cherchent à coller au jeu solo, mais en multijoueur elles peuvent être réduites pour gagner des ressources :

• view-distance : Spigot permet de forcer la distance de rendu des chunks, mais depuis Minecraft 1.18+, il est recommandé de laisser view-distance: default dans spigot.yml et d’utiliser à la place les paramètres de distance de simulation et distance de rendu dans server.properties (ou via Paper). La distance de simulation (simulation-distance) détermine jusqu’où les entités et mécaniques de jeu sont actives, tandis que la distance de vue (view-distance) détermine jusqu’où les chunks sont envoyés visuellement aux clients. L’astuce pour optimiser est de mettre une distance de simulation assez basse (par ex. 4 chunks) tout en conservant une distance de vue plus élevée (ex. 8 chunks ou plus) – ainsi les joueurs voient loin mais le serveur ne tick que les environs proches. Avec Paper, view-distance de spigot.yml doit rester sur “default” pour ne pas interférer, et réglez plutôt simulation-distance = 4 et view-distance = ~7-10 dans les configs Paper/serveur. Pour les versions antérieures à 1.18 qui n’ont pas de simulation-distance séparée, la view-distance dans spigot.yml doit être abaissée directement pour améliorer le TPS. Par exemple, passer de 10 à 6 ou 8 chunks réduit exponentiellement le nombre de zones actives et soulage énormément le serveur.
  
  

• mob-spawn-range : Ce rayon en chunks détermine à quelle distance du joueur les mobs peuvent apparaître. Par défaut c’est 8 chunks (128 blocs), cohérent avec une view-distance de 8, mais on peut le réduire pour concentrer les spawns. Une bonne pratique est de le régler à 4 ou 6 chunks si votre distance de simulation est faible. Veillez à ce que mob-spawn-range reste inférieur ou égal à votre distance de simulation effective (sinon le serveur essaierait de peupler des chunks non simulés). En réduisant ce rayon, on limite la zone d’apparition, donc même avec des spawn-limits réduits on a l’impression qu’il y a toujours des mobs autour du joueur (puisqu’ils spawnent plus près). Par exemple, avec mob-spawn-range: 3 et un plafond de monstres plus bas, les mobs se concentreront dans un petit périmètre, donnant le sentiment d’un monde vivant tout en réduisant leur nombre total. Adaptez ce rayon en fonction des modes de jeu : pour du Skyblock ou des mini-jeux, on peut descendre très bas, alors que pour du PvE puriste on restera modéré. (Versions <1.18 : mob-spawn-range s’applique de même.)
  
  

• entity-activation-range : C’est un des leviers majeurs de performance. Il définit la distance (en blocs) à partir de laquelle les entités arrêtent d’être actives (leur IA est “endormie” tant qu’aucun joueur n’est proche). Par défaut, Spigot utilise typiquement ~32 blocs pour les monstres et animaux. On peut souvent réduire ces valeurs sans impact notable, surtout pour certaines catégories. Par exemple, des portées conseillées sont : monstres 24, animaux 16, mob d’eau 8, villagers 16, monstres volants (phantoms) 48, raiders 48, misc 8. Concrètement, un animal à plus de 16 blocs d’un joueur ne bougera plus jusqu’à ce qu’on s’en rapproche, ce qui est indolore pour le gameplay la plupart du temps. Réduire ces rayons soulage le CPU car les entités lointaines ne consomment plus de ressources. Attention toutefois : si on met des valeurs trop basses, certains mécanismes peuvent se casser. Par exemple, les fermes à fer nécessitent des villagers “actifs” dans un certain rayon des zombies ; si votre activation range des villagers est trop faible, l’usine à fer peut cesser de fonctionner correctement. De même, des mobs “gelés” jusqu’à ce qu’on soit très proche peuvent surprendre les joueurs. Nous conseillons de ne pas descendre en dessous des valeurs indiquées plus haut sauf cas extrême, et de tester les fermes critiques après modification. Enfin, Spigot/Paper offrent aussi une option spécifique tick-inactive-villagers pour faire quand même fonctionner les villageois hors range : nous vous suggérons de la désactiver (tick-inactive-villagers: false), car depuis la 1.14 les villageois ont un impact énorme sur les ticks lorsqu’ils sont actifs en masse. En les laissant s’endormir hors du champ du joueur, vous préservez du TPS, au prix qu’un villageois éloigné ne regénère pas ses trades ou qu’un villageois dans une usine à fer doive attendre qu’un joueur s’approche pour “réagir”. C’est généralement un compromis acceptable étant donné le gain de performance considérable observé sur les serveurs 1.14+ saturés de villagers.
  
  

• entity-tracking-range : Ce paramètre lié définit à quelle distance les entités sont envoyées au client (rendu visible). Il peut être plus grand que l’activation range sans coût serveur significatif, car cela n’affecte que l’envoi des données aux joueurs. Il est conseillé en général de garder les tracking ranges un peu supérieurs aux activation ranges, pour éviter l’effet de mobs qui “pop” soudainement à l’écran. Par exemple, si vos animaux s’activent à 16 blocs, vous pouvez les tracker jusqu’à ~48 blocs pour que le joueur les voie de loin (ils seront juste statiques jusqu’à rapprochement). Des valeurs de 48 pour la plupart des catégories (sauf peut-être les objets “misc” qu’on peut limiter à 32) sont un bon compromis. Ne mettez pas des tracking trop bas (20-30) sinon les joueurs verront les mobs apparaître par surprise tout près d’eux, ce qui est désagréable. Conserver les valeurs par défaut (souvent ~48 pour tout sauf misc) convient dans la majorité des cas.
  
  

• merge-radius : Spigot permet de configurer la distance à laquelle les items et expériences au sol fusionnent entre eux. Fusionner les entités d’item au sol est un excellent moyen de réduire le nombre d’entités à gérer (ex : au lieu de 50 boules d’XP séparées qui tickent individuellement, vous n’en avez plus qu’une ou deux plus grosses). Les valeurs par défaut sont généralement de 4 blocs pour les items et 6 blocs pour les orbes d’XP. Vous pouvez légèrement les augmenter – par exemple items: 4 ou 5 et xp: 6 – mais avec prudence. Si les rayons sont trop grands, la fusion pourrait créer des effets indésirables : des items qui “téléportent” d’un bloc à l’autre en se rassemblant, voire passent à travers les murs pour se rejoindre. Papier a une option pour empêcher la fusion à travers les murs (fix-items-merging-through-walls), utilisez-la si vous agrandissez beaucoup le rayon de merge. En somme, le merge des items est préférable à l’utilisation d’un plugin de nettoyage type ClearLagg : il est natif, automatique et plus fin (on ne supprime pas brutalement les items, on les regroupe). En conjonction avec un despawn plus rapide (voir ci-après), cela évite d’avoir trop d’objets traînant au sol.
  
  

• Durée de vie des entités au sol : Deux paramètres essentiels existent dans Spigot pour éviter l’accumulation d’entités inutiles : arrow-despawn-rate et item-despawn-rate. Par défaut, une flèche tirée par un joueur reste plantée 1 minute (1200 ticks) et un item au sol disparaît au bout de 5 minutes (6000 ticks). Ces durées sont longues et peuvent être raccourcies sans problème pour la performance : il est recommandé de mettre arrow-despawn-rate à ~300 ticks (15 secondes) et item-despawn-rate à ~4000 ticks (~3 minutes). Les flèches tirées (surtout en surplus via des dispensers ou des squelettes) seront nettoyées plus vite, évitant leur accumulation invisible qui charge le serveur. Quant aux items, 3 minutes au lieu de 5 suffisent largement pour qu’un joueur ramasse ses drops ; raccourcir ce délai réduit le risque de milliers d’objets oubliés par terre occupant du temps de tick. Note : Paper propose une configuration plus avancée (alt-item-despawn-rate) permettant de définir un temps de despawn spécifique pour certains items (par exemple faire disparaître plus vite les objets “indésirables” comme le gravier ou la terre). Si vous utilisez Paper/Purpur, envisagez d’activer cette option pour cibler les types d’objets qui encombrent votre monde (par défaut, la config Paper donne 15s pour les blocs courants comme cobble, netherrack, etc.). Cela peut remplacer avantageusement un plugin de clearlag : en paramétrant l’autodestruction accélérée de ces items de farm, le serveur s’auto-régule sans avoir besoin d’une commande de nettoyage global.
  
  

• nerf-spawner-mobs : En passant cette option à true, les mobs issus de spawners (générateurs de donjon, fermes à mobs artificielles) apparaîtront sans intelligence : ils ne bougent pas et n’interagissent pas tant qu’ils n’ont pas été touchés. Cela peut sembler radical, mais si votre serveur a beaucoup de fermes à spawner (zombies, squelettes, etc.), c’est un énorme gain de performances : ces monstres “nerfés” n’ont quasiment aucun coût CPU. Les joueurs pourront toujours les tuer (ils vont juste attendre bêtement au lieu de se déplacer). Pour des serveurs PvE axés survie, on peut hésiter car cela facilite l’exploitation des spawners (les mobs ne se défendent plus) – c’est un choix de game design. Mais sur des serveurs où l’économie et le farm priment, désactiver l’AI des mobs de spawner est recommandé pour empêcher que 200 zombies en attente dans une ferme n’épuisent votre TPS. Paper a même une option associée (spawner-nerfed-mobs-should-jump) pour permettre à ces mobs immobiles de quand même sauter dans l’eau (afin que les systèmes d’eau les déplacent malgré tout). En résumé, si les spawners sont monnaie courante chez vous, alors activez le nerf.
  
  

• save-user-cache-on-stop-only : Cette option, lorsqu’activée (true), fait en sorte que le cache des utilisateurs (fichier .cache contenant des données de UUID/joueurs) ne soit sauvé qu’à l’arrêt du serveur, et non en permanence. Par défaut Spigot l’écrit régulièrement pendant que le serveur tourne, ce qui occasionne des I/O disque fréquentes. En mettant save-user-cache-on-stop-only: true, on améliore légèrement les performances en évitant ces écritures constantes. Attention : le revers est qu’en cas de crash brutal du serveur, le cache non sauvegardé pourrait être perdu, causant possiblement la réapparition de certains joueurs au spawn ou d’autres petits inconvénients (données non critiques). En pratique, ce risque est mineur si vous faites des sauvegardes régulières et que votre serveur ne crashe pas souvent. C’est un gain facile en temps normal, particulièrement utile sur des serveurs très peuplés où la liste des joueurs connectés évolue constamment. N’oubliez pas de stopper proprement le serveur de temps en temps pour flush ce cache.
  
  

• max-tick-time : Spigot introduit un système de “garde-fou” qui saute certains calculs si ceux-ci prennent trop de temps sur un tick. Il y a deux valeurs : une pour les tile entities (blocs à tick type coffres, hoppers, etc.) et une pour les entités mobiles. Par défaut, chacune est à 50 ms. Cela signifie que si, par exemple, le traitement de vos entités dépasse 50 ms sur un tick (ce qui est déjà au-delà de la durée normale de 50ms par tick à 20 TPS), Spigot va arrêter de les tick pour éviter d’aggraver le lag. Si l’intention est bonne (prévenir que le serveur ne s’enfonce dans un lag extrême), en pratique cela peut causer des comportements bizarres (des entités ou machines redstone peuvent rater des cycles car “skippés”). Beaucoup d’administrateurs préfèrent désactiver ce limiter en mettant des valeurs très élevées. Par exemple, mettre max-tick-time.tile et .entity à 1000 (soit 1 seconde) revient à quasiment désactiver la limite (puisqu’il est rare qu’un tick unique dépasse 1s). Shockbyte suggère 1000 pour neutraliser l’effet. Le résultat : le serveur essaiera toujours de tout tick comme prévu, même si cela le mène à un TPS < 20. Vous évitez ainsi des incohérences de jeu causées par le skip. Cependant, gardez à l’esprit que si votre serveur atteint réellement ces seuils, c’est qu’il est gravement surchargé – relever la limite ne résout pas le lag, ça évite juste de masquer le problème. Nous conseillons de mettre 1000 pour ne pas fausser le fonctionnement normal, et de traiter la cause du lag en amont (via les autres optimisations ou l’ajout de ressources). Notez que Paper a son propre watchdog de crash qui n’est pas affecté par ces valeurs.

En appliquant ces ajustements dans spigot.yml, vous devriez constater un gain de TPS notable dans la majorité des cas, car on réduit l’activité lointaine inutile (activation range), on empêche l’accumulation d’entités non essentielles (despawn rapide, merge), et on soulage des points connus (villagers, spawners…). Les valeurs par défaut de Spigot sont conservatrices pour ne pas surprendre le joueur solo, mais en environnement serveur elles sont largement perfectibles – c’est pourquoi des hébergeurs comme Paper intègrent par défaut plusieurs de ces optimisations ou les recommandent d’emblée.

paper.yml (Paper & forks) – Options avancées d’optimisation

Si vous utilisez Paper, Pufferfish ou Purpur, vous disposez de configs supplémentaires par rapport à Spigot. Paper scinde ses configs en plusieurs fichiers (paper-global.yml, paper-world-defaults.yml et des overrides par monde). Pour simplifier, nous parlerons de “paper.yml”, en englobant les principales options disponibles. Ce sont souvent des améliorations désactivées par défaut pour conserver le comportement vanilla absolu, mais qui une fois activées boostent nettement les performances sans conséquence majeure. Parcourons les plus bénéfiques :

• Optimisations du moteur de jeu :

  • Redstone – Paper propose un algorithme alternatif appelé EigenCraft (ou Alternate Current) qui remplace le système vanilla de redstone. Activez use-faster-eigencraft-redstone: true (ou redstone-implementation: ALTERNATE_CURRENT selon la version). Ce nouveau moteur réduit les mises à jour redstone redondantes et améliore grandement les performances des circuits complexes sans changer leur fonctionnement observable. Sauf cas ultra-spécifique de machine redstone bug exploit, il n’y a quasiment pas d’inconvénient à l’utiliser – le gain, lui, est substantiel sur les serveurs où les usines redstone tournent en continu.
    
    

  • Explosions – Passez optimize-explosions sur true pour utiliser l’algorithme optimisé de Paper lors des explosions (TNT, creepers). Celui-ci calcule les zones d’effet plus rapidement, avec une infime perte de précision sur les dégâts ou la physique (invisible pour les joueurs). Depuis Minecraft 1.15, Mojang a déjà un peu amélioré ce point, mais l’option Paper reste bénéfique, en particulier si vos joueurs aiment la TNT ou si vous avez des plugins de minage via explosions.
    
    

  • Anti-Xray – Paper intègre un anti-xray beaucoup plus performant que les plugins traditionnels. Si votre serveur survie souffre de tricheurs x-ray, envisagez d’activer l’anti-xray dans paper.yml (anti-xray sur true, mode engine 2). Cela obfusque les blocs de minerais non découverts en remplaçant temporairement leur apparence dans les chunks envoyés. Le coût CPU de cette fonction existe, mais il est nettement inférieur à celui d’un plugin anti-xray qui rescannerait les chunks et bien moindre que l’impact d’un x-ray classique sur le gameplay (puisque Paper ne touche qu’aux données envoyées). Note : sur les versions très récentes, l’anti-xray de Paper est parfois désactivé par défaut car Mojang a introduit des “blending” de chunks ; vérifiez la doc de votre version. En tout cas, n’utilisez pas de plugin anti-xray tiers sur Paper, utilisez le système natif.
    
    

• Gestion des entités et mobs :
  
  

  • Collisions – Limitez les calculs de collisions d’entités simultanées avec max-entity-collisions. Par défaut 8, on recommande 2 collisions max par entité. Ainsi, dans un gros tas de mobs, chaque entité ne s’occupera que de 2 collisions à la fois au lieu de 8, ce qui réduit l’explosion combinatoire de calculs. À 2, cela suffit pour les cas usuels (même un joueur ne pourra se “pousser” qu’avec 2 entités à la fois, ce qui est largement suffisant). Au-delà, c’est du gaspillage CPU pour détecter des collisions multiples qui de toute façon n’ont pas grande importance de gameplay. Cette option outrepasse celle de Spigot si vous êtes sur Paper. Notez qu’avec max-entity-collisions: 2, la gamerule vanilla maxEntityCramming (qui par défaut tue les entités au-delà de 24 entités empilées) perd un peu de son sens, mais ce n’est pas problématique.
    
    

  • Mobs par joueur – Comme évoqué, activez per-player-mob-spawns: true. Avec ce réglage, le serveur va répartir le mobcap global équitablement entre les joueurs, évitant qu’un joueur isolé monopolise tous les spawns hostiles du serveur en chargeant à lui seul les 70 monstres possibles. Cela rend les spawns plus réguliers et prévisibles pour chacun, un peu comme en solo, et permet de diminuer davantage les spawn-limits sans priver d’action un joueur si un autre est dans une ferme à mobs. L’impact sur le CPU de ce calcul supplémentaire est très faible comparé au bénéfice d’ensemble.
    
    

  • Hoppers – Les entonnoirs (hoppers) sont réputés pour être l’un des pires ennemis du TPS, car ils effectuent par défaut des vérifications constantes (tous les tick) pour voir s’ils peuvent aspirer ou déposer un item. Paper offre plusieurs optimisations :

    • Mettez hopper.disable-move-event: true si et seulement si vous n’utilisez aucun plugin qui écoute l’événement d’inventaire InventoryMoveItemEvent (typiquement des plugins de protection ou de log des items déplacés). En le désactivant, vous évitez que le serveur ne crée un événement à chaque mouvement d’item dans un hopper – ce qui est un gain massif de performance sur les serveurs remplis de circuits de tri ou de stockage. En revanche, si vous avez un plugin de type Lockette, protection de coffres ou autre qui attend ces événements, ne le faites pas sinon ces plugins ne fonctionneront plus correctement.

    • Augmentez le délai de fonctionnement des hoppers : dans spigot.yml, vous avez hopper-transfer (par défaut 8, qui correspond à 8 ticks entre chaque déplacement d’item, soit 2.5 items par seconde) et hopper-check (par défaut 1, qui correspond à “scan” chaque tick s’il y a un item au-dessus). En mettant hopper-transfer à 8 (valeur par défaut, que vous pouvez garder) et hopper-check à 8 (au lieu de 1), vos hoppers ne vérifieront que 2,5 fois par seconde s’il y a un item à aspirer au-dessus au lieu de 20 fois/s. Cela soulage grandement le serveur si vous avez des sols couverts de hoppers, mais cela peut casser certaines horloges Redstone ultra-rapides à base de comparateurs sur des entonnoirs. La valeur de 8 ticks est un compromis souvent conseillé ; elle ralentit légèrement la réactivité de certains systèmes à hoppers, mais reste assez rapide pour la majorité des trieurs d’items (qui sont souvent calibrés sur 8 ticks de toute façon pour la mécanique de cooldown interne des hoppers). Astuce : Testez vos trieurs et fermes à items après ce changement, au besoin ajustez (ex : 4 ticks si 8 cause un souci, ou plus que 8 si vous privilégiez le TPS à tout prix).

    • hopper.ignore-occluding-blocks: true – cette option fait que les hoppers ignorent les conteneurs au travers d’un bloc plein (par ex. un minecart avec hopper enterré dans du sable). En la mettant à true, vous désactivez un comportement vanilla assez spécifique qui n’est pas très utilisé en survie classique, et vous gagnez un peu de performance sur les checks de hopper. Cela peut en revanche casser certaines fermes créatives où on abuse de cette mécanique ; activez-la seulement si vous savez que ce genre de glitch n’est pas employé sur votre serveur.
      
      

  • Villagers – Paper/Purpur ont plusieurs optimisations pour les villageois, qui sont connus pour être très coûteux en 1.14+ à cause de leur AI complexe (recherche de lit, de travail, de chemin…). En plus de tick-inactive-villagers:false déjà mentionné, Purpur propose villager.lobotomize: true qui retire l’AI des villageois trop éloignés de leur objectif. En gros, si un villageois pédale dans la semoule parce qu’il n’arrive pas à aller à son lit ou son poste de travail, le serveur va le “lobotomiser” (il arrête de chercher partout) jusqu’à ce qu’un joueur le libère ou s’en approche à nouveau. Le villageois lobotomisé ne fait plus grand-chose à part restocker ses trades de temps en temps. N’activez ceci qu’en cas de lag massif à cause des villagers, car sinon vous pourriez réduire l’activité normale de vos villages. De même, Purpur permet de réduire les rayons de recherche des villagers pour trouver un lit ou un point d’intérêt (villager.search-radius.acquire-poi etc.) – les mettre à 16 blocs par exemple améliore beaucoup les perfs dans un village géant, au prix que les villagers ne “voient” plus un lit/job trop éloigné. Ces réglages peuvent être utiles si vos joueurs ont construit des trading halls énormes ou des usines à villageois.
    
    

  • Monstres et autres – Purpur offre des petits plus comme zombie.aggressive-towards-villager-when-lagging: false (ainsi, en cas de lag, les zombies arrêtent de poursuivre les villageois, ce qui peut soulager le serveur pendant un pic de charge). Ce n’est pas vital mais c’est une aide ponctuelle en cas de TPS faible. De même, entities-can-use-portals: false désactive le passage des entités (autres que joueurs) dans les portails du Nether. Cela évite que des mobs chargent accidentellement d’autres dimensions en boucle (un gros cochon zombifié traversant un portail allumé va forcer le chargement d’un chunk Nether côté serveur, ce qui est coûteux). En interdisant cela, vous gagnez en stabilité (plus d’énormes pigmen squads qui débarquent au spawn Nether ni de charge inutile). C’est un petit sacrifice de gameplay (les animaux/monstres ne voyageront plus entre monde normal et Nether/End) pour une tranquillité appréciable sur les serveurs publics.
    
    

• Chargement des chunks & monde :
  
  

  • prevent-moving-into-unloaded-chunks: true – Activez absolument cette option sur Paper/Pufferfish. Elle empêche qu’un joueur trop rapide (par ex en elytra) entre dans un chunk non encore généré/chargé, ce qui provoquerait un chargement synchrone très coûteux pouvant geler le serveur. Avec ce paramètre, le joueur sera retenu à la bordure le temps que le chunk charge proprement en arrière-plan, évitant ainsi un gros lag. C’est particulièrement utile si vous avez abaissé la distance de vue : plus celle-ci est faible, plus un joueur rapide a de chances d’atteindre la frontière de chargement et de la dépasser. Ce garde-fou améliore sensiblement la stabilité.
    
    

  • delay-chunk-unloads-by – Paper permet de ne pas décharger immédiatement les chunks quand un joueur s’éloigne. Par défaut, mettre 10s de délai est un bon choix. Ainsi, si un joueur fait un aller-retour rapide ou tourne en rond, le serveur ne va pas sans cesse charger/décharger les mêmes chunks à quelques secondes d’intervalle – il les garde en mémoire un petit moment. Cela évite des opérations IO/CPU répétées. Bien sûr, ne mettez pas un délai trop long non plus, sinon vous garderez beaucoup de chunks inutiles chargés (consommation mémoire accrue). Environ 10 secondes est un compromis validé dans la communauté. Si vous avez des zones très fréquentées par téléportation (spawn, etc.), il peut être judicieux d’utiliser un plugin ou commande pour forcer certains chunks à rester toujours chargés (plutôt que de compter sur un délai).
    
    

  • Pregen du monde – Générer le monde à l’avance peut éliminer les gros pics de lag liés à la création de nouveaux chunks en jeu. Cependant, depuis les versions 1.18+, Mojang a optimisé la génération de terrain et la charge asynchrone, si bien que le pregeneration n’est plus indispensable sauf sur des CPU très lents ou serveurs très limités. Si vous hébergez sur une machine performante, explorer des nouveaux chunks ne devrait plus faire tomber le TPS (ça peut juste ralentir la vitesse de chargement des terrains côté joueur si le CPU est saturé). Néanmoins, pour un lancement de serveur ou un monde stagnant, vous pouvez définir une border et utiliser un plugin comme Chunky pour pré-générer l’intérieur de cette frontière. Cela garantit qu’en jeu, aucune génération lourde n’aura lieu (tout est déjà prêt sur disque) – attention, le processus de pregeneration lui-même est très long et intensif, prévoyez-le en maintenance. Conseil : placez une worldborder sur chacun de vos mondes (Monde, Nether, End) pour éviter que des joueurs ne partent à l’infini générer du terrain inutilement. Une border dans le Nether doit être 8x plus petite proportionnellement (vu l’échelle du Nether). Et si vous activez les cartes aux trésors (voir plus bas), une border est nécessaire pour éviter un lag infini de recherche de trésor hors limites.
    
    

  • Maps au trésor et exploration – Un point souvent méconnu : les cartes au trésor (trouvées dans les épaves, ou vendues par les villageois cartographes) peuvent causer des spikes de lag énormes si elles cherchent des structures très loin. Par défaut, Minecraft veut toujours générer une carte menant à une nouvelle structure non découverte, ce qui peut impliquer de charger des milliers de chunks inédits pour trouver un océan ou un manoir lointain. Paper a une option treasure-maps.enabled – mettez-la sur false pour désactiver complètement les maps au trésor si vous n’en avez que faire (aucun lag, mais plus de maps). Sinon, au minimum, mettez treasure-maps.find-already-discovered: true (pour les loots et les trades), ce qui permet aux cartes de pointer vers des structures déjà générées/découvertes au lieu de toujours chercher du nouveau. Ainsi, un joueur qui farme les cartes au trésor ne va pas crasher le serveur en explorant 10 nouvelles zones océaniques à chaque map – il retournera vers des endroits connus. Important : si vous voulez garder les cartes, assurez-vous d’avoir une worldborder et idéalement d’avoir pré-généré l’intérieur, sinon même avec l’option ci-dessus, la première découverte d’une structure peut faire mal.

Nous venons de couvrir les options Paper/Purpur les plus essentielles. Celles-ci permettent de grignoter chaque milliseconde : en optimisant redstone, collisions, hoppers, etc., vous supprimez quantité de micro-lags qui, cumulés, améliorent nettement la stabilité du TPS. Paper en active d’ailleurs déjà certaines automatiquement (par exemple sync-chunk-writes est forcé à false sur Paper afin que l’écriture des chunks soit asynchrone, alors que sur Vanilla/Spigot vous devez le mettre manuellement dans server.properties). Enfin, retenez que Purpur n’ajoute pas d’optimisations techniques en plus – il se base sur Pufferfish/Paper pour ça. Ce qu’il apporte, ce sont des réglages facultatifs (par exemple le keepalive alternatif pour éviter les timeouts de joueurs lents, ou la désactivation de certaines mécaniques comme vu plus haut). À vous de piocher parmi ces options selon les problèmes spécifiques que vous rencontrez (ex : beaucoup de joueurs se font kicker pour Timed Out ? Essayez use-alternate-keepalive: true de Purpur).

Plugins de performance et outils de gestion

Outre les réglages, certains plugins peuvent aider à diagnostiquer ou atténuer les problèmes de performances. Voici une sélection d’outils éprouvés qui ont un impact réel sur la fluidité ou l’administration du serveur :

• Spark – Indispensable pour qui veut profiler son serveur. Spark est un plugin qui permet d’enregistrer des profils de performance CPU et mémoire de votre serveur en temps réel. En exécutant la commande /spark profiler pendant quelques secondes, puis /spark profiler --stop, vous obtenez un rapport très détaillé sur ce qui consomme du temps CPU (tâches, entités, plugins, etc.) ou de la mémoire. Il inclut aussi un viewer web pratique. C’est l’outil parfait pour identifier la cause de vos lag spikes (par exemple, découvrir qu’un certain type de mob ou qu’une fonction d’un plugin monopolise 40% du temps de tick). Spark offre en prime des commandes /spark tps, /spark health et même /spark profiler --memory pour traquer un éventuel leak mémoire. En bref : utilisez Spark en cas de problèmes de TPS inexpliqués, c’est le profiler le plus complet et léger pour Minecraft.
  
  

• Timings (intégré Paper/Spigot) – Ce n’est pas un plugin, mais il faut le mentionner. La commande /timings report (ou /timings paste) génère un rapport des tâches les plus lourdes sur votre serveur depuis le dernier reset de timings. Paper améliore grandement l’outil Timing par rapport à Spigot, fournissant des graphiques de charge et le détail des événements, fonctions et même des entités les plus coûteuses. Pensez à l’utiliser régulièrement pour orienter vos optimisations : par exemple, des timings pourront révéler que la gestion des chunks occupe 40% du tick (signe qu’il faut baisser la view-distance ou pregen), ou qu’un plugin de shop consomme trop, etc. Combiné à Spark pour aller plus finement, c’est votre tableau de bord de performance.
  
  

• FarmLimiter / FarmControl – Ce type de plugin surveille et limite la taille des regroupements d’entités (monstres ou animaux) dans les fermes AFK. Un problème courant sur les serveurs survie : les joueurs créent d’énormes fermes à mobs ou animaux (ex : 500 vaches dans un enclos minuscule, ou des “stack” de monstres dans un coin d’eau). Même avec les réglages de spawn-limits, de telles concentrations peuvent survenir via l’élevage ou les spawners. FarmLimiter (ou son successeur moderne FarmControl) permet par exemple de définir qu’au-delà de 30 mobs du même type dans un rayon donné, les nouveaux spawn sont bloqués ou les mobs en trop sont supprimés progressivement. C’est un moyen préventif de contenir les abus qui ruinent les TPS. Un bon plugin du genre saura distinguer les mobs naturels et ceux des spawners, et agir en douceur (par ex, empêcher l’élevage quand la limite est atteinte, plutôt que de massacrer vos animaux). Note : Avec Paper, vous pouvez déjà limiter certains aspects (par ex. la règle max-entity-collisions:2 et le cram rule évitent que 500 entités se stackent physiquement), mais FarmControl va plus loin en gérant les cas de figure variés (trop de mobs autour d’un joueur, accumulation d’items dans des fermes, etc.). Si votre communauté aime les usines extrêmes, c’est un ajout salutaire.
  
  

• ClearLag(g) – Plugin ancien mais connu, il nettoie périodiquement les entités au sol, les mobs en trop, etc., via un système de tâches planifiées et de commandes (ex: annonce “Nettoyage dans 60 sec” puis suppression des items). Avis : ClearLag peut résoudre ponctuellement une surcharge (il “poubelle” tout ce qui traîne), mais c’est plus un pansement qu’une solution pérenne. Souvent, bien configurer les despawn et merges d’items rend ClearLag superflu. En outre, ClearLag lui-même consomme des ressources pour scanner l’ensemble des entités régulièrement. Si votre configuration de base est solide (comme détaillée plus haut), vous ne devriez pas avoir besoin de ce plugin. On le mentionne car beaucoup l’utilisent par habitude. Préférez-lui les solutions natives (merge, alt-despawn) ou ciblées (FarmLimiter pour les mobs). ClearLag peut toutefois être utile pour ses autres fonctions : il peut limiter la distance de spawn des mobs hostiles en temps réel selon le TPS, gérer un vide d’items quand un chunk dépasse X entités, etc. Si vous l’installez, utilisez-le plutôt en “sécurité filet” qu’en béquille principale.
  
  

• VillagerOptimizer – Si malgré tout vos villageois restent un problème (par ex, des villages de 100+ villagers provoquant du lag), vous pouvez essayer ce plugin. Il réduit la fréquence à laquelle les villagers effectuent certaines tâches coûteuses (recherche de lit, pathfinding). En gros, il “ralentit” leur cerveau pour qu’ils ne sollicitent pas le serveur 20 fois par seconde chacun. C’est similaire aux réglages Purpur sur les villager tick rates, mais en plugin utilisable sur Spigot/Paper également. Certains plugins similaires offrent aussi la possibilité de désactiver la régénération des stocks de trade illimitée (pour éviter que les usines à trade tournent sans fin). Avant d’utiliser ce genre de plugin, assurez-vous d’avoir déjà réglé tick-inactive-villagers:false et éventuellement réduit villager.tick-rate via Paper (Paper/Purpur ont une section tick-rates où l’on peut espacer certains checks des villagers). Souvent cela suffit. VillagerOptimizer est surtout utile sur Spigot, qui n’a pas toutes ces optimisations natives.
  
  

• Chunky – Plugin de pré-génération de monde. Comme évoqué plus haut, générer vos cartes à l’avance peut éliminer les lags d’exploration. Chunky est un outil simple et performant pour ça : vous définissez un rayon ou des bordures, et il va remplir progressivement tous les chunks dans ces limites. Il fonctionne de manière asynchrone pour ne pas effondrer votre serveur pendant l’opération, mais prévoyez de le faire en période creuse. Après coup, vous pouvez désinstaller le plugin. C’est utile en début de serveur ou si vous ajoutez un nouveau monde/dimension et que vous voulez anticiper l’exploration par les joueurs. Gardez en tête qu’avec Paper et au-delà, le chargement asynchrone des chunks est optimisé : en théorie, un explorateur ne fait plus chuter le TPS brutalement, ça peut juste ralentir son propre chargement de chunks s’il va trop vite. Donc la pregénération est un plus de confort, mais pas une nécessité absolue sur les versions récentes sauf contexte particulier (matériel faible ou besoin d’une carte Dynmap).
  
  

• Plugins d’analyse du lag – En plus de Spark, mentionnons TickTools, LagMonitor ou Minebench. Ce sont des plugins qui monitorent votre TPS, mémoire, et parfois loggent les événements longs (>50ms). Par exemple, LagMonitor peut vous alerter quand un certain plugin déclenche un Garbage Collection de 200ms, etc. Utile pour les administrateurs qui veulent être proactifs, mais pas indispensable. Paper intègre déjà /mspt pour voir le temps moyen par tick, et ses timings suffisent souvent.

Bien sûr, il existe d’autres plugins axés performance (ex: NoMobLag qui ajuste dynamiquement les spawn en fonction du TPS, LimitPillagers qui limite l’afflux de pillards autour des avant-postes, etc.). Sélectionnez les outils en fonction des problèmes que vous observez. Évitez les plugins miracles qui promettent de “multithreader” le serveur ou d’optimiser magiquement sans compromis – 99% du temps c’est inefficace ou pire, dangereux. Les solutions sérieuses sont celles qui ciblent un aspect précis (profiling, limitation de mobs, etc.) ou qui tirent parti des mécanismes offerts par Paper.

Pour finir sur les plugins, un rappel : ne rechargez pas vos plugins à chaud en production. Les commandes comme /reload ou des plugins permettant de charger/décharger un plugin sans redémarrer sont connues pour provoquer fuites de mémoire, incohérences et crashs. Préférez un redémarrage propre du serveur après avoir ajouté/retiré des plugins. Cela garantit la stabilité sur le long terme.

Configuration de l’environnement Java (JVM, matériel)

Optimiser Minecraft ne s’arrête pas aux configs du jeu : l’environnement d’exécution Java et les ressources allouées importent également.

Version de Java : Assurez-vous d’utiliser une version de Java à jour et supportée. Depuis Minecraft 1.18, la version minimale est Java 17, et pour Minecraft 1.20.5+ il faut Java 21 ou supérieur. Évitez Java 8 ou 11 sur les serveurs modernes – non seulement elles ne sont plus supportées par les dernières versions de MC, mais en plus les améliorations du langage et du garbage collector dans Java 17/21 apportent des gains de performance et de stabilité non négligeables.

Garbage Collector (GC) : Minecraft serveur utilise intensivement la mémoire, générant beaucoup de “garbage” (objets temporaires). Un mauvais réglage du GC peut provoquer des pauses de plusieurs centaines de ms (provoquant des saccades/TPS bas). Heureusement, Java 17+ utilise par défaut le garbage collector G1GC, qui est bien adapté aux charges type MC. Il est toutefois conseillé de tuner les flags JVM pour G1GC en vue d’un serveur. La communauté recommande souvent les « flags d’Aikar », du nom d’un développeur Paper qui a popularisé une configuration optimisée de la JVM. Ces flags visent à réduire les pauses et à lisser le comportement du GC. Plutôt que de les lister ici (car ils évoluent avec le temps), le mieux est d’utiliser un générateur de flags mis à jour. Par exemple, le site flags.sh vous fournit automatiquement la ligne de commande adéquate en fonction de votre version de Java et de la RAM que vous voulez allouer. Les guides Paper pointent aussi vers la documentation officielle et la Spigot Optimisation Guide pour les flags recommandés. En règle générale, suivez ces principes :

• Allouez suffisamment de RAM : trop peu de mémoire (<4 Go) forcera le GC à tourner constamment. Mais n’allouez pas excessivement non plus (évitez de mettre 32 Go juste “parce que”), car G1 fonctionne mieux dans un tas raisonnable qu’il peut régulièrement nettoyer. Pour un serveur classique 50 joueurs sans mod, 8 Go sont souvent suffisants. Ajustez selon vos besoins (moniteurs via l’utilisation via Spark ou timings si possible).
  
  

• Fixez Xms = Xmx : c’est un conseil standard – définissez la même valeur pour le heap minimal et maximal (ex: -Xms8G -Xmx8G). Ainsi, la JVM alloue tout d’entrée et n’a pas besoin d’étendre/réduire dynamiquement le tas, ce qui évite des délais inutiles en cours de route.
  
  

• Utilisez G1GC : sur Java 17+, c’est déjà le GC par défaut. Les flags recommandés pour G1 incluent souvent : -XX:MaxGCPauseMillis=200 (cible de pause max ~200ms, à ajuster), -XX:+ParallelRefProcEnabled (accélère le nettoyage de références), -XX:+AlwaysPreTouch (pré-alloue la mémoire pour éviter des ralentissements ultérieurs), -XX:G1NewSizePercent=30 etc. Plutôt que de tous les expliquer, fiez-vous au bundle de flags fourni par Aikar ou le générateur, qui ont fait leurs preuves. Attention : certains flags très anciens (ex: UseConcMarkSweepGC ou UseParallelOldGC) sont obsolètes ou contre-productifs – ne les utilisez pas sur Java récents.
  
  

• Surveillez le GC : même avec de bons flags, gardez un œil sur le fonctionnement du GC. La commande /spark gc ou certains timings peuvent vous indiquer le % de temps passé en GC. Idéalement, cela doit rester faible (<5%). Si vous constatez des stop-the-world fréquents, il faudra ajuster (augmenter la RAM, ou diagnostiquer une fuite mémoire potentielle).
  
  

• JVM alternatifs : Bien que des JVM comme OpenJ9 ou GraalVM existent, Paper et Spigot ne les supportent pas officiellement et ils peuvent causer des problèmes imprévisibles. Leur bénéfice sur un serveur MC n’est pas avéré dans la plupart des cas, surtout comparé à la maturité de G1GC.

Autres conseils système :

• CPU : Minecraft est essentiellement monothread (sauf certaines tâches en backend). La fréquence et l’IPC du processeur priment donc sur le nombre de cores. Sur un dédié/VM, privilégiez moins de cores mais plus rapides. C'est exactement pour cela que nous proposons les MyBoxPerf ! 

• I/O et disque : Avec Paper, beaucoup d’opérations disque (sauvegardes chunks) sont async, mais un disque lent peut tout de même être un goulot d’étranglement. Utilisez un SSD/NVMe pour le stockage du monde si possible. Là aussi, les offres MyBox et MyBoxPerf vous couvrent.

• Réseau : Indirectement lié aux performances, le paramètre network-compression-threshold (dans server.properties) peut être ajusté. Par défaut à 256 octets, cela signifie que les paquets de moins de 256 octets ne sont pas compressés. Sur de vraies connexions internet de joueurs, gardez 256 ou montez à 512 si vous voulez réduire la charge CPU au prix de quelques kB de plus par paquet. La compression réseau pèse peu dans le TPS en général, sauf sur des serveurs bondés (100+ joueurs) où ça devient non négligeable.

En somme, maintenez votre environnement Java à jour et optimisé : une bonne version de Java, les bons flags, suffisamment de mémoire et un CPU véloce sont les fondations sur lesquelles vos optimisations de config pourront briller.

Conclusion et derniers conseils

En appliquant les recommandations de ce guide, vous devriez obtenir un serveur nettement plus stable et performant, capable de tenir le 20 TPS dans bien des situations où la configuration par défaut aurait vacillé. Pour récapituler quelques points-clés :

• Utilisez un moteur performant : passez à Paper ou un fork optimisé plutôt que Spigot; profitez des patchs de performance éprouvés.

• Ajustez les configs : réduisez les distances de simulation, limites de spawn, durées de despawn et portées d’activation pour éliminer le travail inutile. Activez les options d’optimisation Paper (redstone alternatif, collisions réduites, anti-xray, etc.) pour gagner sur tous les tableaux.

• Surveillez constamment : servez-vous de Spark pour identifier les sources de lag. L’optimisation est un processus continu : chaque nouvelle farm construite ou plugin ajouté peut introduire un point faible. Réagissez en conséquence en ajustant configs ou en ajoutant un plugin de contrôle (FarmLimiter, etc.) si besoin.

• Imposez des limites : ne laissez pas les joueurs faire n’importe quoi au détriment du serveur. Annoncez clairement vos règles d’entités (par ex : “pas plus de 50 mobs par chunk”) et utilisez des outils pour les faire respecter automatiquement si nécessaire. Vos joueurs préfèreront un léger cap sur leurs usines plutôt qu’un serveur injouable à 5 TPS.

• Soyez prêt aux compromis : un serveur 100% vanilla au niveau comportement et 100% fluide n’existe pas pour une charge élevée. Choisissez vos batailles : vaut-il mieux des villagers un peu moins “intelligents” ou un spawn de 200 villageois qui paralyse tout ? La question est vite répondue. Communiquez avec vos joueurs sur ces ajustements, la plupart comprennent qu’un petit sacrifice individuel améliore l’expérience collective.

• Mettez à jour intelligemment : tenez vos softwares (Paper, Purpur…) à jour, ils intègrent souvent de nouvelles optimisations ou correctifs de performance. Lisez les changelogs. De même, restez informé des évolutions (ex : Folia, un futur serveur multi-threadé de Paper, promet d’intéressants gains dans certaines conditions – à suivre lorsque stable). Ne passez pas à côté d’une amélioration facile juste par conservatisme.

Enfin, n’oubliez pas que chaque serveur est unique. Ce guide vous fournit une base solide, mais à vous de la peaufiner : testez progressivement les changements (idéalement un par un pour voir leur effet), mesurez l’impact via /timings ou profilers sparks, et ajustez. Faites participer vos modérateurs ou joueurs de confiance pour repérer d’éventuels effets secondaires (une ferme qui marche moins bien, etc.). L’optimisation est un équilibre entre performance, stabilité et gameplay, en suivant les conseils ici et en restant attentif, vous trouverez cet équilibre et votre serveur s’en portera mieux. Bon tuning, et bon jeu à tous sur un serveur fluide et optimisé !

Sources : Guide d’optimisation YouHaveTrouble, documentations, guides officiels Paper/Purpur, et expériences de la communauté.