Optimisation serveur Minecraft
Guide complet Spigot, Paper et Purpur (1.20-1.21)
Les performances d'un serveur Minecraft reposent sur une configuration logicielle et matérielle adaptée. Ce guide s'adresse aux administrateurs utilisant Spigot, Paper ou des forks similaires comme Purpur et Pufferfish, et couvre les versions 1.20.x à 1.21.x. Nous détaillerons les réglages essentiels des fichiers de configuration (spigot.yml, paper.yml, bukkit.yml, purpur.yml), expliquerons pourquoi les valeurs par défaut sont souvent inadaptées, et montrerons comment des ajustements ciblés améliorent le TPS, réduisent la charge CPU et stabilisent votre serveur.
Ce guide inclut également des recommandations de plugins utiles, une comparaison des avantages de Purpur et Pufferfish face à Paper et Spigot, ainsi que des conseils sur la configuration Java (versions, flags JVM G1GC). Le contenu est organisé par sections pour une consultation rapide et efficace.
Choisir son logiciel serveur
Comparatif des solutions disponibles
| Logiciel | Base | Avantage principal | Recommandé pour |
|---|---|---|---|
| Spigot | CraftBukkit | Compatibilité plugins historique | Petits serveurs simples |
| Paper | Spigot | Optimisations + options avancées | Majorité des serveurs |
| Pufferfish | Paper | Performance maximale | Serveurs très peuplés |
| Purpur | Pufferfish | Personnalisation poussée | Serveurs nécessitant des options exotiques |
Paper plutôt que Spigot
Spigot et son prédécesseur CraftBukkit constituent la base historique des serveurs Bukkit, mais ils accusent aujourd'hui un retard en termes de performance face à Paper. Ce dernier est un fork de Spigot intégrant de nombreuses optimisations et correctifs tout en conservant une compatibilité totale avec les plugins Spigot et Bukkit. Paper expose également des dizaines d'options de configuration avancées permettant d'affiner les performances sans altérer significativement le gameplay.
Pufferfish pour la performance pure
Pufferfish est un fork de Paper apparu en 2021, entièrement orienté vers la performance. Il intègre de nombreux patchs avancés tout en restant compatible avec l'API Paper.
Améliorations incluses dans Pufferfish :
| Fonctionnalité | Description |
|---|---|
| Traitement asynchrone | Certaines entités sont traitées partiellement en arrière-plan |
| Système DAB | Algorithmes d'IA de mob plus rapides |
| Rendu des cartes SIMD | Optimisation via instructions vectorielles |
| Gestion des hoppers | Fonctionnement plus efficient des entonnoirs |
| Optimisation ray tracing | Calculs de lignes de vue accélérés |
| Gestion mémoire | Réduction des pauses du garbage collector |
| Intégration Sentry.io | Remontée automatique des erreurs serveur |
| Profiler Flare | Analyses avancées incluant le profilage mémoire |
La plupart de ces optimisations sont transparentes pour le gameplay. Celles susceptibles d'avoir un impact peuvent être désactivées dans pufferfish.yml. Si votre objectif est de supporter un grand nombre de joueurs avec une charge élevée, Pufferfish représente souvent le meilleur choix.
Note : Il existe également Pufferfish+, une version commerciale encore plus optimisée avec suivi d'entités et pathfinding entièrement asynchrones, destinée aux très gros serveurs.
Purpur pour la personnalisation
Purpur est un fork de Paper orienté vers la personnalisation poussée. Techniquement, il inclut toutes les optimisations de Pufferfish mais n'ajoute pas de gain de performance supplémentaire propre. En revanche, il offre des centaines de nouvelles options de configuration pour ajuster les mécanismes de jeu : possibilité de monter certains mobs, calamars volants, sommeil d'un seul joueur, et bien d'autres.
Par défaut, ces fonctionnalités supplémentaires sont désactivées et le serveur se comporte comme un Paper/Pufferfish standard. N'utilisez Purpur que si vous avez réellement besoin de ces options de gameplay, car davantage de patchs signifie potentiellement davantage de bugs.
Ce qu'il faut éviter
| À éviter | Raison |
|---|---|
| JAR "maison" obscurs ou payants | 99% de chances d'inefficacité voire de nuisance |
| Serveur Vanilla pur | Écart de performance notable avec Paper |
| Rester sur Spigot | Vous perdez les optimisations Paper gratuitement disponibles |
Configuration bukkit.yml
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 calibrées pour de petits serveurs peu peuplés mais s'avèrent excessives pour un serveur survie avec de nombreux joueurs.
Limites de spawn (spawn-limits)
Ces quotas définissent le nombre de mobs pouvant spawner par joueur. Par défaut, un joueur peut avoir jusqu'à environ 70 monstres, 10 animaux et 15 créatures aquatiques autour de lui, ce qui peut rapidement saturer le serveur en entités avec plusieurs joueurs connectés.
Valeurs recommandées :
| Catégorie | Valeur par défaut | Valeur recommandée |
|---|---|---|
| Monstres | 70 | 20 à 30 |
| Animaux | 10 | 5 |
| Créatures aquatiques | 15 | 2 |
| Créatures ambiantes | 15 | 1 |
Le calcul interne multiplie ces limites par le nombre de joueurs connectés. En réduisant ces chiffres, vous diminuez la densité de mobs à gérer et allégez la charge serveur.
Attention : Des valeurs trop basses réduisent la faune et la difficulté du jeu. Pour un serveur survie "hardcore" ou axé sur les fermes à mobs, ne descendez pas trop bas. La valeur de 30 monstres offre un bon compromis si vous souhaitez conserver de l'action.
Fréquences de spawn (ticks-per)
Ces réglages contrôlent la fréquence des tentatives de 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 (environ 20 secondes).
Valeurs recommandées :
| Catégorie | Valeur par défaut | Valeur recommandée |
|---|---|---|
| monster-spawns | 1 | 2 à 10 |
| animal-spawns | 400 | 400 |
| water-spawns | 1 | 400 |
| ambient-spawns | 1 | 400 |
Mettre monster-spawns à 2 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. Pour les catégories aquatiques et ambiantes, des intervalles de 400 ticks ou plus sont parfaitement acceptables puisque ces créatures atteignent rapidement leur plafond de population.
Option complémentaire Paper
Paper offre l'option per-player-mob-spawns 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, vous pouvez vous permettre des limites plus basses sans priver les joueurs de rencontres : chaque joueur aura sa part équitable de mobs autour de lui.
Configuration spigot.yml
Le fichier spigot.yml 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 à reproduire le comportement solo, mais en multijoueur elles peuvent être réduites pour économiser des ressources.
Distances de vue et simulation
| Paramètre | Description | Recommandation |
|---|---|---|
| view-distance | Distance de rendu des chunks | Laisser sur "default" dans spigot.yml |
| simulation-distance | Distance d'activité des entités | 4 chunks (server.properties ou Paper) |
| view-distance (effective) | Chunks envoyés au client | 7 à 10 chunks |
Depuis Minecraft 1.18+, il est recommandé de laisser view-distance sur "default" dans spigot.yml et d'utiliser les paramètres de distance dans server.properties ou via Paper. L'astuce consiste à définir une distance de simulation basse (4 chunks) tout en conservant une distance de vue plus élevée (8 à 10 chunks). Ainsi, les joueurs voient loin mais le serveur ne calcule que les environs proches.
Rayon de spawn des mobs (mob-spawn-range)
Ce rayon en chunks détermine à quelle distance du joueur les mobs peuvent apparaître. Par défaut fixé à 8 chunks (128 blocs), il peut être réduit pour concentrer les spawns.
Recommandation : Réglez ce paramètre à 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. En réduisant ce rayon, même avec des spawn-limits réduits, les joueurs auront l'impression d'un monde vivant puisque les mobs apparaîtront plus près d'eux.
Portée d'activation des entités (entity-activation-range)
C'est l'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).
Valeurs recommandées :
| Catégorie | Valeur par défaut | Valeur recommandée |
|---|---|---|
| Monstres | 32 | 24 |
| Animaux | 32 | 16 |
| Créatures aquatiques | 32 | 8 |
| Villageois | 32 | 16 |
| Monstres volants (phantoms) | 32 | 48 |
| Raiders | 32 | 48 |
| Misc | 16 | 8 |
Réduire ces rayons soulage le CPU car les entités lointaines ne consomment plus de ressources. Cependant, des valeurs trop basses peuvent casser certains mécanismes. Par exemple, les fermes à fer nécessitent des villageois "actifs" dans un certain rayon des zombies.
Conseil : Activez également tick-inactive-villagers: false pour que les villageois s'endorment hors du champ du joueur. Depuis la 1.14, les villageois ont un impact énorme sur les ticks lorsqu'ils sont actifs en masse.
Portée de tracking des entités (entity-tracking-range)
Ce paramètre définit à quelle distance les entités sont envoyées au client. 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.
Recommandation : Gardez les tracking ranges un peu supérieurs aux activation ranges pour éviter l'effet de mobs qui "pop" soudainement à l'écran. Des valeurs de 48 pour la plupart des catégories (sauf misc à 32) constituent un bon compromis.
Fusion des items et XP (merge-radius)
| Type | Valeur par défaut | Valeur recommandée |
|---|---|---|
| Items | 2.5 | 4 à 5 |
| XP | 3.0 | 6 |
Fusionner les entités d'items au sol réduit considérablement le nombre d'entités à gérer. Au lieu de 50 boules d'XP séparées, vous n'en avez plus qu'une ou deux plus grosses. N'augmentez pas trop ces rayons car des items pourraient "téléporter" d'un bloc à l'autre ou traverser les murs pour se rejoindre.
Astuce : Paper propose l'option fix-items-merging-through-walls pour empêcher ce comportement si vous agrandissez beaucoup le rayon de merge.
Durée de vie des entités au sol
| Paramètre | Valeur par défaut | Valeur recommandée |
|---|---|---|
| arrow-despawn-rate | 1200 ticks (1 min) | 300 ticks (15 sec) |
| item-despawn-rate | 6000 ticks (5 min) | 4000 ticks (3 min) |
Les flèches tirées seront nettoyées plus rapidement, évitant leur accumulation invisible. Pour les items, 3 minutes suffisent largement pour qu'un joueur ramasse ses drops.
Note Paper : L'option alt-item-despawn-rate permet de définir un temps de despawn spécifique pour certains items (cobble, netherrack, gravier). Cela peut remplacer avantageusement un plugin de clearlag.
Autres paramètres importants
| Paramètre | Valeur recommandée | Description |
|---|---|---|
| nerf-spawner-mobs | true | Les mobs de spawners n'ont plus d'IA jusqu'à être touchés |
| save-user-cache-on-stop-only | true | Le cache utilisateurs n'est sauvé qu'à l'arrêt |
| max-tick-time (tile et entity) | 1000 | Désactive quasi totalement le limiteur de tick |
nerf-spawner-mobs : Si votre serveur possède beaucoup de fermes à spawner, c'est un énorme gain de performance. Les monstres "nerfés" n'ont quasiment aucun coût CPU et attendent simplement d'être tués.
max-tick-time : En mettant 1000ms, vous désactivez le système de garde-fou qui peut causer des comportements bizarres (entités ou machines redstone qui ratent des cycles). Le serveur essaiera toujours de tout calculer comme prévu, même si cela le mène à un TPS inférieur à 20.
Configuration paper.yml
Paper et ses forks disposent de configurations supplémentaires par rapport à Spigot. Ces options sont souvent des améliorations désactivées par défaut pour conserver le comportement vanilla, mais une fois activées elles boostent nettement les performances.
Optimisations du moteur de jeu
Redstone optimisée
| Option | Valeur | Description |
|---|---|---|
| use-faster-eigencraft-redstone | true | Active l'algorithme EigenCraft |
| redstone-implementation | ALTERNATE_CURRENT | Alternative 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.
Explosions optimisées
| Option | Valeur | Description |
|---|---|---|
| optimize-explosions | true | Algorithme optimisé pour TNT et creepers |
L'algorithme calcule les zones d'effet plus rapidement avec une perte de précision imperceptible pour les joueurs.
Anti-Xray intégré
| Option | Valeur | Description |
|---|---|---|
| anti-xray.enabled | true | Active la protection |
| anti-xray.engine-mode | 2 | Mode d'obfuscation recommandé |
L'anti-xray de Paper est bien plus performant que les plugins traditionnels. Il obfusque les blocs de minerais non découverts en remplaçant temporairement leur apparence dans les chunks envoyés. N'utilisez jamais de plugin anti-xray tiers sur Paper.
Gestion des entités et mobs
Collisions réduites
| Option | Valeur par défaut | Valeur recommandée |
|---|---|---|
| max-entity-collisions | 8 | 2 |
Dans un gros tas de mobs, chaque entité ne s'occupera que de 2 collisions à la fois au lieu de 8, réduisant l'explosion combinatoire de calculs.
Spawns par joueur
| Option | Valeur recommandée |
|---|---|
| per-player-mob-spawns | true |
Le serveur répartit le mobcap global équitablement entre les joueurs, évitant qu'un joueur isolé monopolise tous les spawns hostiles.
Optimisation des hoppers
Les entonnoirs sont réputés pour être l'un des pires ennemis du TPS car ils effectuent des vérifications constantes.
| Option | Valeur | Condition |
|---|---|---|
| hopper.disable-move-event | true | Uniquement si aucun plugin n'écoute InventoryMoveItemEvent |
| hopper-transfer (spigot.yml) | 8 | Valeur par défaut acceptable |
| hopper-check (spigot.yml) | 8 | Au lieu de 1 par défaut |
| hopper.ignore-occluding-blocks | true | Désactive un comportement vanilla peu utilisé |
En désactivant disable-move-event, vous évitez que le serveur ne crée un événement à chaque mouvement d'item dans un hopper. C'est un gain massif de performance sur les serveurs remplis de circuits de tri.
Attention : Si vous utilisez des plugins de protection de coffres ou de log des items déplacés, ne désactivez pas cette option.
Optimisations des villageois
| Option | Valeur | Description |
|---|---|---|
| tick-inactive-villagers | false | Les villageois s'endorment hors du champ du joueur |
| villager.lobotomize (Purpur) | true | Retire l'IA des villageois trop éloignés de leur objectif |
| villager.search-radius.* (Purpur) | 16 | Réduit les rayons de recherche de lit/travail |
Options diverses Purpur
| Option | Valeur | Description |
|---|---|---|
| zombie.aggressive-towards-villager-when-lagging | false | Les zombies arrêtent de poursuivre les villageois en cas de lag |
| entities-can-use-portals | false | Empêche les mobs de traverser les portails |
| use-alternate-keepalive | true | Évite les timeouts de joueurs lents |
Chargement des chunks et monde
Protection contre les chunks non chargés
| Option | Valeur recommandée |
|---|---|
| prevent-moving-into-unloaded-chunks | true |
Cette option empêche qu'un joueur trop rapide (en elytra par exemple) entre dans un chunk non encore généré, ce qui provoquerait un chargement synchrone très coûteux pouvant geler le serveur.
Délai de déchargement
| Option | Valeur recommandée |
|---|---|
| delay-chunk-unloads-by | 10s |
Si un joueur fait un aller-retour rapide, le serveur ne va pas sans cesse charger/décharger les mêmes chunks. Cela évite des opérations IO/CPU répétées.
Cartes au trésor
| Option | Valeur | Description |
|---|---|---|
| treasure-maps.enabled | false | Désactive complètement les maps au trésor |
| treasure-maps.find-already-discovered | true | Les cartes pointent vers des structures déjà découvertes |
Les cartes au trésor peuvent causer des spikes de lag énormes si elles cherchent des structures très loin. Si vous les conservez, assurez-vous d'avoir une worldborder et idéalement d'avoir prégénéré l'intérieur.
Prégénération du monde
Depuis les versions 1.18+, Mojang a optimisé la génération de terrain et la charge asynchrone. La prégénération n'est plus indispensable sauf sur des CPU très lents. Néanmoins, pour un lancement de serveur, vous pouvez utiliser un plugin comme Chunky pour prégénérer l'intérieur de votre worldborder.
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. La border du Nether doit être 8 fois plus petite proportionnellement.
Plugins de performance recommandés
Tableau récapitulatif
| Plugin | Fonction | Indispensable |
|---|---|---|
| Spark | Profiler CPU et mémoire | ✅ Oui |
| Timings (intégré) | Rapport des tâches lourdes | ✅ Oui |
| FarmLimiter/FarmControl | Limite les regroupements d'entités | Selon besoin |
| Chunky | Prégénération de monde | Selon besoin |
| VillagerOptimizer | Réduit la fréquence des tâches villageois | Selon besoin |
| ClearLag | Nettoyage périodique des entités | ⚠️ Pansement |
Spark
Indispensable pour profiler son serveur. Spark permet d'enregistrer des profils de performance CPU et mémoire en temps réel.
Commandes utiles :
| Commande | Fonction |
|---|---|
/spark profiler | Démarre l'enregistrement |
/spark profiler --stop | Arrête et génère le rapport |
/spark tps | Affiche le TPS actuel |
/spark health | État de santé du serveur |
/spark gc | Informations sur le garbage collector |
/spark profiler --memory | Traque les fuites mémoire |
C'est l'outil parfait pour identifier la cause de vos lag spikes : découvrir qu'un certain type de mob ou qu'une fonction d'un plugin monopolise 40% du temps de tick.
Timings (intégré Paper/Spigot)
La commande /timings report génère un rapport des tâches les plus lourdes depuis le dernier reset. Paper améliore grandement cet outil par rapport à Spigot, fournissant des graphiques de charge et le détail des événements les plus coûteux.
FarmLimiter / FarmControl
Ce type de plugin surveille et limite la taille des regroupements d'entités dans les fermes AFK. Un problème courant : les joueurs créent d'énormes fermes à mobs ou 500 vaches dans un enclos minuscule.
Fonctionnement : Au-delà d'un seuil (par exemple 30 mobs du même type dans un rayon donné), les nouveaux spawns sont bloqués ou les mobs en trop sont supprimés progressivement.
ClearLag
Plugin connu qui nettoie périodiquement les entités au sol et les mobs en trop.
Avis : ClearLag peut résoudre ponctuellement une surcharge, mais c'est plus un pansement qu'une solution pérenne. Bien configurer les despawn et merges d'items rend souvent ClearLag superflu. De plus, ClearLag lui-même consomme des ressources pour scanner l'ensemble des entités régulièrement.
Chunky
Plugin de prégénération de monde simple et performant. Vous définissez un rayon ou des bordures et il remplit progressivement tous les chunks. Il fonctionne de manière asynchrone pour ne pas effondrer votre serveur pendant l'opération.
VillagerOptimizer
Si vos villageois restent un problème malgré les réglages, ce plugin réduit la fréquence de leurs tâches coûteuses (recherche de lit, pathfinding). C'est similaire aux réglages Purpur mais utilisable sur Spigot/Paper.
Ce qu'il faut éviter
| À éviter | Raison |
|---|---|
| Plugins "miracles" promettant du multithreading | 99% inefficaces ou dangereux |
Commande /reload en production | Provoque fuites mémoire et crashs |
| Charger/décharger des plugins à chaud | Incohérences et instabilité |
Préférez toujours un redémarrage propre du serveur après avoir ajouté ou retiré des plugins.
Configuration Java et JVM
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 requise
| Version Minecraft | Version Java minimale |
|---|---|
| 1.17 et antérieures | Java 8 ou 11 |
| 1.18 à 1.20.4 | Java 17 |
| 1.20.5 et supérieures | Java 21 |
Évitez Java 8 ou 11 sur les serveurs modernes. Les améliorations du langage et du garbage collector dans Java 17/21 apportent des gains de performance et de stabilité non négligeables.
Configuration du Garbage Collector
Minecraft serveur utilise intensivement la mémoire, générant beaucoup d'objets temporaires. Un mauvais réglage du GC peut provoquer des pauses de plusieurs centaines de millisecondes.
Principes recommandés :
| Principe | Recommandation |
|---|---|
| RAM suffisante | 8 Go pour un serveur classique de 50 joueurs |
| Xms = Xmx | Définir la même valeur pour heap min et max |
| Garbage Collector | G1GC (défaut sur Java 17+) |
| Générateur de flags | Utiliser flags.sh pour obtenir les flags optimaux |
Exemple de ligne de commande :
java -Xms8G -Xmx8G -XX:+UseG1GC -XX:MaxGCPauseMillis=200 -XX:+ParallelRefProcEnabled -XX:+AlwaysPreTouch -jar server.jar nogui
Conseil : Utilisez le générateur de flags sur flags.sh qui fournit automatiquement la ligne de commande adéquate en fonction de votre version de Java et de la RAM à allouer.
Surveillance du GC
La commande /spark gc ou certains timings peuvent vous indiquer le pourcentage de temps passé en GC. Idéalement, cela doit rester faible (inférieur à 5%). Si vous constatez des pauses fréquentes, augmentez la RAM ou diagnostiquez une éventuelle fuite mémoire.
JVM alternatives
| JVM | Recommandation |
|---|---|
| OpenJ9 | ⚠️ Non supportée officiellement |
| GraalVM | ⚠️ Non supportée officiellement |
| HotSpot (standard) | ✅ Recommandée |
Bien que des JVM alternatives existent, Paper et Spigot ne les supportent pas officiellement et elles peuvent causer des problèmes imprévisibles.
Conseils système
| Composant | Recommandation |
|---|---|
| CPU | Privilégier la fréquence au nombre de cœurs |
| Stockage | SSD/NVMe pour le monde |
| network-compression-threshold | 256 (défaut) ou 512 pour serveurs 100+ joueurs |
Minecraft est essentiellement monothread. La fréquence et l'IPC du processeur priment donc sur le nombre de cœurs.
Conclusion et recommandations
En appliquant les recommandations de ce guide, vous obtiendrez un serveur nettement plus stable et performant, capable de maintenir 20 TPS dans des situations où la configuration par défaut aurait vacillé.
Récapitulatif des points clés
| Domaine | Action prioritaire |
|---|---|
| Logiciel serveur | Passer à Paper ou un fork optimisé |
| Distances | Réduire simulation-distance et activation ranges |
| Spawns | Diminuer les limites et augmenter les intervalles |
| Entités | Activer nerf-spawner-mobs et tick-inactive-villagers: false |
| Redstone | Activer l'algorithme alternatif Paper |
| Hoppers | Augmenter hopper-check et désactiver move-event si possible |
| Monitoring | Utiliser Spark régulièrement |
| Java | Utiliser Java 17/21 avec flags G1GC optimisés |
Bonnes pratiques continues
Surveillez constamment : Servez-vous de Spark pour identifier les sources de lag. L'optimisation est un processus continu car chaque nouvelle ferme ou plugin ajouté peut introduire un point faible.
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 et utilisez des outils pour les faire respecter automatiquement.
Acceptez les compromis : Un serveur 100% vanilla au niveau comportement et 100% fluide n'existe pas pour une charge élevée. Vaut-il mieux des villagers un peu moins "intelligents" ou un spawn de 200 villageois qui paralyse tout ? La question est vite répondue.
Mettez à jour intelligemment : Tenez vos logiciels (Paper, Purpur) à jour car ils intègrent souvent de nouvelles optimisations. Lisez les changelogs et restez informé des évolutions comme Folia, le futur serveur multi-threadé de Paper.
Chaque serveur est unique. Ce guide vous fournit une base solide à peaufiner : testez progressivement les changements (idéalement un par un), mesurez l'impact via Spark ou timings, et ajustez selon vos observations.
Pour tester ces optimisations sur une infrastructure performante, découvrez nos offres de serveurs Minecraft gratuits et constatez la différence en conditions réelles !