Comment optimiser votre serveur Minecraft sans casser vos fermes

Réduire simulation-distance n’est pas la même chose que réduire view-distance. L’une modifie la zone, centrée sur le joueur, que le serveur simule ; l’autre contrôle la quantité de données de terrain envoyées aux joueurs. Un paysage lointain peut rester visible alors qu’une ferme située là-bas ne se comporte plus comme son propriétaire l’attend.

Cette distinction compte davantage que la recherche d’une configuration étiquetée « optimisée ». Un serveur plus calme n’est guère une amélioration si les villageois ne se réapprovisionnent plus ou si un spot AFK établi ne fonctionne plus. L’objectif est de supprimer le travail dont votre communauté peut se passer, puis de vérifier que le gameplay que vous vouliez conserver fonctionne toujours.

Ce tutoriel concerne les serveurs Minecraft Java Edition modernes. Les paramètres de distance s’appliquent à Vanilla, Spigot et Paper ; les commandes de plugins et les paramètres YAML sont signalés séparément. Ce n’est pas une recette universelle pour Bedrock, les modpacks ou Folia. Vérifiez la documentation par rapport à la version exacte de votre serveur : les références actuelles peuvent décrire des versions plus récentes, et ni les valeurs par défaut ni l’organisation des fichiers ne restent figées.

1. Mesurez le problème pendant qu’il se produit

Notez votre version de Minecraft, votre logiciel serveur et son build, le nombre de joueurs et ce que font les joueurs au moment du ralentissement. Une salle d’échanges bondée et un groupe qui explore du terrain vierge sont deux charges de travail différentes. Profiler un serveur vide n’expliquera ni l’une ni l’autre ; la documentation de Paper exige explicitement que le problème se produise pendant la collecte.

Sur Paper, spark est intégré depuis la version 1.21. Sur Spigot, installez d’abord un plugin spark autonome compatible ; les commandes suivantes ne sont pas intégrées à un serveur Vanilla non modifié.

Exécutez-les en jeu avec les permissions requises :

code

/spark tps
/spark profiler start --timeout 600

La commande du profiler enregistre pendant dix minutes et renvoie l’URL d’un rapport. Conservez ce rapport avec votre configuration et vos notes sur la charge de travail.

Au rythme normal, Minecraft vise 20 TPS, ce qui laisse 50 millisecondes par tick. Le MSPT décrit la durée des ticks, il révèle donc une pression que la seule valeur de TPS peut masquer. Comparez le MSPT médian et au 95e centile : ce dernier aide à repérer les ticks lents récurrents, mais peut passer à côté des pics rares. Vérifiez aussi le maximum, plutôt que de considérer qu’un bon centile prouve qu’aucun blocage n’a eu lieu.

Pour les problèmes intermittents, le tick monitor de spark peut signaler les ticks qui dépassent ce budget :

code

/spark tickmonitor --threshold-tick 50

Notez ce qui s’est passé au même moment. Si les temps de tick restent bons pendant la plainte, étudiez la fréquence d’images du client ou les conditions réseau avant de sacrifier le gameplay du serveur.

2. Sauvegardez et identifiez les paramètres qui s’appliquent réellement

Avant toute modification, arrêtez proprement le serveur et sauvegardez les mondes, les fichiers de configuration et les données des plugins. Conservez la sauvegarde en dehors du répertoire du serveur en production et vérifiez que vous pouvez la restaurer. Une copie de la configuration facilite le retour arrière ; une sauvegarde du monde protège le travail qu’il contient.

Utilisez un éditeur de texte, respectez l’indentation YAML et ne changez qu’une chose par expérience. Démarrez ensuite normalement le serveur et inspectez le journal de démarrage à la recherche d’erreurs de configuration. N’utilisez pas /reload ni un chargeur à chaud de plugins comme raccourci : recharger des plugins peut laisser les dépendances et l’état incohérents.

Pour Vanilla, commencez par server.properties. Pour Spigot et Paper, examinez aussi spigot.yml : les paramètres de distance par monde peuvent remplacer le fichier de propriétés.

Cet extrait illustre l’héritage, pas un préréglage de performance :

yaml

world-settings:
  default:
    view-distance: default
    simulation-distance: default

Ici, default indique à ces options d’utiliser server.properties. Fusionnez les clés dans la section existante ; ne remplacez pas tout le fichier et n’ajoutez pas un second bloc world-settings. Vérifiez aussi les sections de mondes nommés, car une valeur propre à un monde peut remplacer le paramètre partagé.

Si vous remplacez des valeurs numériques par l’héritage, considérez-le comme un changement distinct et relevez une nouvelle référence. Sinon, vous risquez de modifier plusieurs distances effectives avant votre premier test contrôlé.

3. Séparez la visibilité du terrain de la simulation

Les deux distances se mesurent en chunks autour du joueur, et non en blocs ni en diamètre.

view-distance contrôle la quantité de données du monde envoyées au client. La réduire sacrifie la visibilité du terrain lointain contre moins de travail pour maintenir cette vue disponible.
simulation-distance contrôle la zone de ticks centrée sur le joueur. La réduire peut diminuer le travail de simulation, mais modifie aussi la zone dans laquelle les fermes et entités proches fonctionnent.

Une zone de vue bleue simplifiée et une zone de simulation ambrée plus petite autour du même joueur. D’autres règles de chargement et de proximité s’appliquent également.

La distance de vue n’est pas gratuite du simple fait qu’une partie du terrain se trouve hors de la distance de simulation. De même, la réduire ne remplace pas la correction d’un plugin coûteux. Choisissez la première expérience d’après le profil et le compromis de gameplay que vous pouvez accepter.

Essayez un seul changement de distance

Supposons que votre server.properties actuel contienne :

properties

view-distance=10
simulation-distance=10

Si le profil pointe vers le travail de ticking sur les zones chargées, une expérience consiste à laisser la distance de vue inchangée et à réduire un peu la distance de simulation :

properties

view-distance=10
simulation-distance=8

Ces chiffres sont des exemples, pas des valeurs par défaut universelles ni un préréglage SharpHeberg testé. Si votre distance de vue actuelle est différente, laissez votre propre valeur. Redémarrez proprement, reproduisez la charge de travail d’origine et collectez un nouveau rapport avant toute réduction supplémentaire.

Si le profil suggère plutôt que le problème vient du maintien ou de l’envoi du terrain lointain, testez la distance de vue séparément. N’abaissez pas les deux paramètres ensemble pour essayer ensuite de deviner lequel a aidé.

La distance de simulation n’est pas un règlement complet pour les fermes. Les tickets de chunks, qui maintiennent des chunks chargés pour des raisons précises, et les exigences de proximité des joueurs diffèrent selon les mécaniques et les versions. « Chargé » ne garantit pas que l’apparition des mobs, la pousse des cultures, les entités et les entités de bloc se comportent de la même manière. Vérifiez les exigences de votre ferme plutôt que de supposer qu’une seule distance en garantit le fonctionnement.

L’apparition et la disparition naturelles des mobs ont aussi leurs propres règles de distance ; mob-spawn-range de Spigot et les paramètres de despawn de Paper ajoutent d’autres réglages. Si une ferme cesse de fonctionner après l’expérience, commencez par rétablir la distance précédente. Ne compensez pas immédiatement en modifiant plusieurs paramètres d’apparition.

4. Sur Spigot ou Paper, examinez le travail des entités avant de réduire les portées

Si le profil pointe vers le traitement des entités, inspectez la zone concernée. Cherchez les objets au sol qui s’accumulent, les enclos surpeuplés ou une salle d’échanges qui fait un travail inutile. Coordonnez-vous avec les propriétaires avant de modifier des constructions. Réduire une source identifiée de travail excessif est plus facile à évaluer que d’affaiblir partout le comportement des entités.

Deux options de spigot.yml aux noms proches ont des rôles différents :

Paramètre	Unité	Ce qu’il contrôle
`entity-activation-range`	Blocs	À quelle distance les entités doivent se trouver des joueurs pour être mises à jour normalement ; le comportement hors de cette portée est limité.
`entity-tracking-range`	Blocs	À quelle distance les entités sont envoyées aux joueurs, ce qui influe sur le moment où elles deviennent visibles.

Ce sont des contrôles d’entités, et non les distances en chunks vues plus haut. Une portée de suivi plus faible peut faire apparaître les mobs brusquement ; ce n’est pas équivalent à réduire leur charge d’IA.

Les changements d’activation demandent une attention particulière autour des fermes à fer et des villageois. Les conseils de la communauté documentent des fermes cassées et des problèmes de réapprovisionnement causés par une activation trop agressive ou par des changements sur les villageois inactifs. Ne touchez pas à ces paramètres sans que le profilage justifie le compromis, puis testez la catégorie d’entités concernée plutôt que de copier un préréglage complet.

La même prudence s’applique à nerf-spawner-mobs, au timing des hoppers et aux changements de fusion d’objets : ils modifient le comportement, pas seulement la consommation de ressources. Ne réduisez pas aveuglément les limites de mobs et n’installez pas de suppression planifiée d’entités comme première réponse au lag.

5. Considérez les paramètres de Paper comme des réglages propres à chaque version

Paper possède des couches de configuration supplémentaires. Son organisation documentée inclut config/paper-global.yml pour les paramètres globaux et config/paper-world-defaults.yml pour les paramètres de mondes partagés. Le paper-world.yml d’un monde peut remplacer ces valeurs par défaut.

Localisez ce fichier de remplacement à l’aide de la documentation de votre build. L’organisation des répertoires des mondes et des dimensions varie ; copier un chemin issu d’un ancien tutoriel peut vous envoyer au mauvais endroit. Ne copiez que les paramètres que vous voulez remplacer, pas tout le fichier de valeurs par défaut.

Paper propose des réglages pour l’apparition, la disparition, les collisions et le comportement des hoppers. Ce sont des options pour un problème identifié, pas une liste à cocher. Par exemple, désactiver l’événement de déplacement des hoppers peut casser les plugins de protection qui en dépendent. Un petit gain de timing ne justifierait pas de contourner discrètement une règle du serveur.

La référence spigot.yml citée est maintenue par Paper et inclut des comportements propres à Paper. Ne supposez pas que chaque option imbriquée qu’elle documente existe ou se comporte de la même façon sur un Spigot pur. Consultez la configuration générée pour votre implémentation et votre version avant d’ajouter une clé.

6. Suivez le profil au-delà des paramètres de distance

Examinez le travail des plugins

Si le rapport pointe vers la tâche d’un plugin, conservez le rapport et vérifiez la configuration, la compatibilité et les notes de version de ce plugin. Paper recommande explicitement de partager un rapport spark pertinent avec les développeurs de plugins lors de l’analyse de problèmes de performance.

Reproduisez le problème si possible sur une copie de test sauvegardée. Modifiez une fonctionnalité ou un plugin à la fois, en respectant les dépendances, puis répétez la même activité. Évitez de désactiver les plugins de protection ou d’économie sur le serveur en production juste pour voir si les TPS remontent.

Gardez aussi le réglage de Java et de la mémoire guidé par les mesures. Examinez le comportement du ramasse-miettes et les prérequis Java de votre build de serveur exact avant de modifier les options de démarrage. Une collection copiée de flags GC n’est pas une étape d’optimisation universelle.

Ne prégénérez que lorsque la génération est le problème

Lorsque le ralentissement coïncide avec l’exploration, comparez les déplacements dans du terrain existant et dans du terrain nouveau. Si le profilage désigne la génération de chunks comme le goulot d’étranglement, la prégénération déplace ce travail de génération avant le jeu normal. Chunky fournit des outils à cet effet.

Choisissez la zone et les dimensions voulues, vérifiez l’espace disque et la capacité de sauvegarde, et planifiez le travail en dehors des heures chargées. Testez d’abord une zone limitée. La prégénération ne supprime pas le coût du chargement ou de l’envoi des chunks existants, ni celui des fermes qu’ils contiennent.

Les guides communautaires ne s’accordent pas sur le degré de recommandation de la prégénération pour les serveurs modernes. Considérez-la comme une réponse à une pression de génération mesurée, pas comme une maintenance obligatoire pour toute installation Paper.

7. Vérifiez le gameplay avant de conserver le changement

Répétez la charge de travail d’origine avec un nombre et une répartition de joueurs comparables. Conservez ensemble les rapports spark avant et après, la différence de configuration et vos notes. Refaites la comparaison si les conditions ont changé sensiblement.

Testez ensuite le serveur comme le font les joueurs :

Faites fonctionner les fermes importantes depuis leurs positions AFK habituelles, y compris la collecte et le transport.
Vérifiez les échanges avec les villageois et leur réapprovisionnement sur un cycle de travail normal.
Faites tourner les trieurs à hoppers et les horloges assez longtemps pour révéler des objets manqués ou un timing altéré.
Vérifiez la visibilité et le comportement des mobs pendant les déplacements, et testez chaque monde concerné.

Ne conservez un changement que si l’amélioration mesurée est utile et le compromis de gameplay acceptable. Si le bénéfice n’est pas clair, rétablissez la valeur précédente. Ne désactivez jamais la sauvegarde pour embellir un graphique de performance.

Si le goulot d’étranglement restant semble être la capacité d’hébergement, appuyez-vous sur le rapport pour guider cette discussion. Vous pouvez consulter l’hébergement Minecraft de SharpHeberg en fonction de votre charge de travail et de vos besoins. Les choix d’hébergement et les changements de configuration méritent le même test : le serveur fonctionne-t-il mieux tout en préservant la façon de jouer de votre communauté ?

Lectures associées : Le vrai coût d’un serveur Minecraft hautes performances en 2025. Considérez les prix de cet article plus ancien comme historiques, et non comme les tarifs actuels.