Tu choisis les services que nous pouvons activer pour l’analyse, la personnalisation et les contenus externes.
Nous utilisons des cookies et des technologies similaires sur notre site pour personnaliser les contenus, intégrer des médias externes et mieux comprendre l’utilisation de certaines sections.
Cookies nécessaires
Ces entrées assurent des fonctions essentielles comme la sécurité, la stabilité et le traitement des formulaires.
Tes données peuvent être traitées avec ton consentement ou sur la base d’intérêts légitimes. Dans les paramètres des cookies, tu peux refuser chaque catégorie facultative ou l’autoriser individuellement.
Certains services traitent des données personnelles dans des pays tiers. En donnant ton consentement, tu acceptes également ce transfert. Pour en savoir plus, consulte notre politique de confidentialité.
Tu pourras rouvrir et modifier ta sélection à tout moment. · 1.0.2
Découvre comment optimiser les serveurs de jeu Minecraft pour de meilleures performances et un gameplay plus fluide grâce à des conseils de configuration efficaces → En savoir plus
10 novembre 202622 min de lecture0 Vues0 utile
Que se passe-t-il exactement lors de l’optimisation ?
L’optimisation est une étape importante pour assurer le bon fonctionnement des serveurs de jeu Minecraft. Si tu gères un serveur public, prends le temps de t’en occuper. Seuls de nombreux tests et un peu de patience permettent d’obtenir le meilleur résultat. Ce guide n’est donc pas une marche à suivre à appliquer à la lettre, mais plutôt une aide pour t’orienter dans la bonne direction.
Dans la plupart des cas, l’optimisation consiste à modifier de nombreux paramètres du serveur, ce qui peut changer considérablement son comportement. Certains paramètres sont notamment réduits, ce qui allège la charge du serveur et peut ainsi améliorer ses performances. Pour ne pas trop nuire à l’expérience de jeu, veille à trouver le juste milieu.
Vanilla
Les possibilités d’optimisation d’un serveur Vanilla sont malheureusement très limitées, car peu de paramètres sont disponibles. Voici quelques mesures qui peuvent donner un peu plus de puissance à ton serveur Vanilla :
Distance d’affichage
Réduire la distance d’affichage est une mesure très courante. La distance par défaut est de 10 chunks, mais de nombreux joueurs en utilisent beaucoup moins, par exemple 6 à 8. Certains vont trop loin et la règlent, par exemple, sur 32. Le serveur doit alors charger et traiter tous ces chunks, ce qui lui coûte beaucoup de ressources.
Sur un serveur Vanilla, tu peux modifier la distance d’affichage dans la configuration server.properties, en changeant la valeur view-distance. Pour ne pas trop limiter l’expérience de jeu, nous te conseillons de régler cette valeur sur 5 ou 6, ce qui peut réduire la charge du serveur jusqu’à 50 %.
Nous avons déjà consacré une page de notre guide à ce sujet, que tu trouveras ici.
Compression des données
Un échange constant a lieu entre le serveur et les joueurs qui y sont connectés. Les déplacements des joueurs sont envoyés au serveur, qui les transmet à son tour aux autres joueurs. Les actions des joueurs et les événements du monde, comme les explosions, font également partie des données régulièrement transférées.
Pour rendre ces échanges plus efficaces, tu peux doubler la taille des données compressées. Le serveur n’aura alors besoin que de 50 % des ressources nécessaires pour échanger les mêmes données avec les joueurs. Pour cela, modifie la valeur network-compression-threshold dans la configuration server.properties. Nous te conseillons de la régler sur 512. Nous avons également consacré une page de notre guide à ce sujet, que tu trouveras ici.
FAQ
Questions fréquentes
La distance d’affichage est de 10 chunks par défaut. La réduire à 5 ou 6 dans server.properties (valeur view-distance) peut alléger la charge du serveur jusqu’à 50 %, sans trop limiter l’expérience de jeu.
L’article présente des optimisations pour Vanilla, Forge, Bukkit, Spigot et Paper Spigot. Paper Spigot offre le plus de paramètres supplémentaires, notamment pour les limites d’apparition, la portée d’activation des entités, les générateurs de monstres et la redstone.
Un serveur Vanilla offre peu de paramètres par rapport à des plateformes comme Spigot ou Paper Spigot. Les optimisations se limitent donc principalement à la distance d’affichage et à la compression des données.
Non. Ce guide est là pour t’aider, pas pour te donner une marche à suivre obligatoire. L’optimisation peut modifier considérablement le comportement du serveur : prends donc le temps de faire des tests et de trouver le bon équilibre entre performances et expérience de jeu.
Avis
Cet article t’a-t-il été utile ?
Ton avis nous aide à mieux définir les priorités et à améliorer les contenus.
0 de 0 Les personnes ayant donné leur avis ont trouvé cet article utile.
Aide personnalisée
Le guide ne suffit pas ?
Notre équipe d’assistance ZAP connaît ton produit : décris brièvement ta demande et nous t’aiderons personnellement.
Navigation
Minecraft
Forge
Comme pour Vanilla, les possibilités d’intervention directe sur le serveur sont malheureusement assez limitées, car les fichiers de configuration disponibles sont peu nombreux et très courts. Il est toutefois possible d’installer des mods supplémentaires pour alléger quelque peu la charge du serveur.
Pré-génération des chunks
La pré-génération des chunks permet d’alléger la charge du serveur. Celui-ci n’aura ensuite qu’à charger les données des chunks déjà enregistrées lorsque des joueurs se connecteront, au lieu de créer et de générer les chunks de toutes pièces. Il est préférable de lancer ce processus le soir et de le laisser tourner pendant la nuit.
Pour cela, tu dois installer un mod supplémentaire. Tu peux télécharger un mod particulièrement adapté ici.
Tu peux ensuite l’installer normalement sur le serveur, comme indiqué dans nos guides.
Avant de redémarrer le serveur, vérifie que max-tick-time est réglé sur -1 dans server.properties. Sinon, le serveur risque de planter. Nous te conseillons également de prévoir au moins 8 à 10 Go de RAM, car ce processus en consomme beaucoup. Tu peux augmenter temporairement la mémoire vive pendant la nuit, puis la réduire à nouveau après.
Infos
Note que le mod mentionné ci-dessus n’est pas forcément compatible avec ta version de Forge et que la procédure peut varier si tu utilises un autre mod.
Une fois le serveur démarré avec le mod, ouvre la console. Nous te conseillons de définir une limite de monde d’un rayon de 16 000 blocs. Pour cela, exécute les commandes suivantes l’une après l’autre :
worldborder center 0 0
worldborder set 16000
Infos
Si nécessaire, remplace les coordonnées par celles du centre de ton monde afin qu’il ne soit pas « coupé » (par exemple, si des constructions s’y trouvent déjà).
Une fois la limite définie, tu peux lancer la pré-génération. Pour cela, exécute la commande suivante :
pregen gen startWorldBorder
Tous les chunks situés à l’intérieur de la limite sont maintenant pré-générés les uns après les autres. Selon le nombre de mods installés, cette opération peut durer jusqu’à 8 heures. La progression s’affiche régulièrement dans la console sous forme de messages d’information. La console t’indiquera également lorsque le processus sera terminé !
Infos
Tu peux laisser le mod installé sur le serveur une fois le processus terminé. Il continue d’optimiser les chunks pendant que le serveur fonctionne, même en l’absence de joueurs.
Distance d’affichage
Réduire la distance d’affichage est une mesure très courante. La distance par défaut est de 10 chunks, mais de nombreux joueurs en utilisent beaucoup moins, par exemple 6 à 8. Certains vont trop loin et la règlent, par exemple, sur 32. Le serveur doit alors charger et traiter tous ces chunks, ce qui lui coûte beaucoup de ressources.
Tu peux modifier la distance d’affichage d’un serveur Forge dans la configuration server.properties, en changeant la valeur view-distance. Pour ne pas trop limiter l’expérience de jeu, nous te conseillons de régler cette valeur sur 5 ou 6, ce qui peut réduire la charge du serveur jusqu’à 50 %.
Nous avons déjà consacré une page de notre guide à ce sujet, que tu trouveras ici.
Compression des données
Un échange constant a lieu entre le serveur et les joueurs qui y sont connectés. Les déplacements des joueurs sont envoyés au serveur, qui les transmet à son tour aux autres joueurs. Les actions des joueurs et les événements du monde, comme les explosions, font également partie des données régulièrement transférées.
Pour rendre ces échanges plus efficaces, tu peux doubler la taille des données compressées. Le serveur n’aura alors besoin que de 50 % des ressources nécessaires pour échanger les mêmes données avec les joueurs. Pour cela, modifie la valeur network-compression-threshold dans la configuration server.properties. Nous te conseillons de la régler sur 512. Nous avons également consacré une page de notre guide à ce sujet, que tu trouveras ici.
Bukkit
Distance d’affichage
Réduire la distance d’affichage est une mesure très courante. La distance par défaut est de 10 chunks, mais de nombreux joueurs en utilisent beaucoup moins, par exemple 6 à 8. Certains vont trop loin et la règlent, par exemple, sur 32. Le serveur doit alors charger et traiter tous ces chunks, ce qui lui coûte beaucoup de ressources.
Tu peux modifier la distance d’affichage d’un serveur Bukkit dans la configuration server.properties, en changeant la valeur view-distance. Pour ne pas trop limiter l’expérience de jeu, nous te conseillons de régler cette valeur sur 5 ou 6, ce qui peut réduire la charge du serveur jusqu’à 50 %.
Nous avons déjà consacré une page de notre guide à ce sujet, que tu trouveras ici.
Compression des données
Un échange constant a lieu entre le serveur et les joueurs qui y sont connectés. Les déplacements des joueurs sont envoyés au serveur, qui les transmet à son tour aux autres joueurs. Les actions des joueurs et les événements du monde, comme les explosions, font également partie des données régulièrement transférées.
Pour rendre ces échanges plus efficaces, tu peux doubler la taille des données compressées. Le serveur n’aura alors besoin que de 50 % des ressources nécessaires pour échanger les mêmes données avec les joueurs. Pour cela, modifie la valeur network-compression-threshold dans la configuration server.properties. Nous te conseillons de la régler sur 512. Nous avons également consacré une page de notre guide à ce sujet, que tu trouveras ici.
Limites d’apparition
Cette étape consiste à réduire légèrement le taux d’apparition général des créatures sur le serveur. La différence avec les valeurs par défaut est à peine perceptible. Il peut toutefois arriver que certaines fermes à créatures ne fonctionnent pas comme prévu.
Pour modifier ces paramètres, édite le fichier de configuration bukkit.yml. Change les valeurs suivantes sous spawn-limits :
monsters: 50 #Standard: 70
animals: 10 #Standard: 15
water-animals: 3 #Standard: 5
ambient: 4 #Standard: 15
Infos
Tu peux bien sûr ajuster ces valeurs toi-même si tu le souhaites. Sinon, les valeurs ci-dessus constituent un très bon compromis.
Pour améliorer encore l’apparition des créatures, modifie également la valeur monster-spawns dans l’entrée ticks-per du fichier bukkit.yml :
monster-spawns: 2 #Standard: 1
En cas de problème général avec les monstres, par exemple si tu le constates dans le rapport de timing, tu peux augmenter la valeur jusqu’à 5. Observe alors le comportement du serveur avec chaque valeur pour trouver celle qui lui convient le mieux.
Traitement des chunks
Minecraft utilise ce qu’on appelle des chunks. Un chunk est composé de 16 x 16 blocs regroupés qui permettent au client de représenter visuellement le monde. Le serveur travaille donc uniquement avec des chunks et charge en RAM ceux dont il a besoin. Plus le serveur charge et traite de chunks en continu, plus il doit leur consacrer de ressources, ce qui peut finir par le mettre à genoux.
Avec les paramètres par défaut, les serveurs ne déchargent jamais les chunks chargés. La RAM peut donc être fortement sollicitée et une quantité énorme de mémoire peut être nécessaire. Les performances du serveur s’en trouvent malheureusement fortement réduites, car il doit traiter toujours plus de données.
Pour que le serveur ne charge que les chunks dont il a besoin à ce moment-là, tu peux modifier l’option suivante sous chunk-gc dans le fichier bukkit.yml :
period-in-ticks: 300 #Standard: 600
Infos
L’ancienne valeur supplémentaire load-threshold n’existe plus dans les versions actuelles de Paper, Spigot et Bukkit. Paper limite de toute façon period-in-ticks à un maximum de 20 ticks (1 seconde) côté serveur. Une valeur plus élevée n’a donc pratiquement plus aucun effet sur un serveur basé sur Paper (par exemple Paper Spigot).
L’option period-in-ticks détermine à quels intervalles, en secondes, les chunks sont déchargés. Tu peux réduire davantage cette valeur si tu le souhaites, mais attention : cela peut entraîner un effet indésirable, une boucle.
Dans ce cas, un chunk serait déchargé alors qu’il serait de nouveau nécessaire peu après. Le serveur devrait alors consacrer à nouveau du temps et des ressources à son chargement. Le phénomène se répéterait, imposant au serveur une charge plus importante que si les chunks restaient chargés une minute de plus, par exemple.
Spigot
Distance d’affichage
Réduire la distance d’affichage est une mesure très courante. La distance par défaut est de 10 chunks, mais de nombreux joueurs en utilisent beaucoup moins, par exemple 6 à 8. Certains vont trop loin et la règlent, par exemple, sur 32. Le serveur doit alors charger et traiter tous ces chunks, ce qui lui coûte beaucoup de ressources.
Sur un serveur Spigot, tu peux modifier la distance d’affichage dans la configuration spigot.yml, en changeant la valeur view-distance. Pour ne pas trop limiter l’expérience de jeu, nous te conseillons de régler cette valeur sur 5 ou 6, ce qui peut réduire la charge du serveur jusqu’à 50 %.
Infos
Selon tes préférences, tu peux aussi régler cette valeur sur 4. Cela peut notamment aider à réduire les lags si tu gères des serveurs de mondes de farm sous la version 1.13 ou une version ultérieure.
Compression des données
Un échange constant a lieu entre le serveur et les joueurs qui y sont connectés. Les déplacements des joueurs sont envoyés au serveur, qui les transmet à son tour aux autres joueurs. Les actions des joueurs et les événements du monde, comme les explosions, font également partie des données régulièrement transférées.
Pour rendre ces échanges plus efficaces, tu peux doubler la taille des données compressées. Le serveur n’aura alors besoin que de 50 % des ressources nécessaires pour échanger les mêmes données avec les joueurs. Pour cela, modifie la valeur network-compression-threshold dans la configuration server.properties. Nous te conseillons de la régler sur 512. Nous avons également consacré une page de notre guide à ce sujet, que tu trouveras ici.
Limites d’apparition
Cette étape consiste à réduire légèrement le taux d’apparition général des créatures sur le serveur. La différence avec les valeurs par défaut est à peine perceptible. Il peut toutefois arriver que certaines fermes à créatures ne fonctionnent pas comme prévu.
Pour modifier ces paramètres, édite le fichier de configuration bukkit.yml. Change les valeurs suivantes sous spawn-limits :
monsters: 50 #Standard: 70
animals: 10 #Standard: 15
water-animals: 3 #Standard: 5
ambient: 4 #Standard: 15
Infos
Tu peux bien sûr ajuster ces valeurs toi-même si tu le souhaites. Sinon, les valeurs ci-dessus constituent un très bon compromis.
Pour améliorer encore l’apparition des créatures, modifie également la valeur monster-spawns dans l’entrée ticks-per du fichier bukkit.yml :
monster-spawns: 2 #Standard: 1
En cas de problème général avec les monstres, par exemple si tu le constates dans le rapport de timing, tu peux augmenter la valeur jusqu’à 5. Observe alors le comportement du serveur avec chaque valeur pour trouver celle qui lui convient le mieux.
Traitement des chunks
Minecraft utilise ce qu’on appelle des chunks. Un chunk est composé de 16 x 16 blocs regroupés qui permettent au client de représenter visuellement le monde. Le serveur travaille donc uniquement avec des chunks et charge en RAM ceux dont il a besoin. Plus le serveur charge et traite de chunks en continu, plus il doit leur consacrer de ressources, ce qui peut finir par le mettre à genoux.
Avec les paramètres par défaut, les serveurs ne déchargent jamais les chunks chargés. La RAM peut donc être fortement sollicitée et une quantité énorme de mémoire peut être nécessaire. Les performances du serveur s’en trouvent malheureusement fortement réduites, car il doit traiter toujours plus de données.
Pour que le serveur ne charge que les chunks dont il a besoin à ce moment-là, tu peux modifier l’option suivante sous chunk-gc dans le fichier bukkit.yml :
period-in-ticks: 300 #Standard: 600
Infos
L’ancienne valeur supplémentaire load-threshold n’existe plus dans les versions actuelles de Paper, Spigot et Bukkit. Paper limite de toute façon period-in-ticks à un maximum de 20 ticks (1 seconde) côté serveur. Une valeur plus élevée n’a donc pratiquement plus aucun effet sur un serveur basé sur Paper (par exemple Paper Spigot).
L’option period-in-ticks détermine à quels intervalles, en secondes, les chunks sont déchargés. Tu peux réduire davantage cette valeur si tu le souhaites, mais attention : cela peut entraîner un effet indésirable, une boucle.
Dans ce cas, un chunk serait déchargé alors qu’il serait de nouveau nécessaire peu après. Le serveur devrait alors consacrer à nouveau du temps et des ressources à son chargement. Le phénomène se répéterait, imposant au serveur une charge plus importante que si les chunks restaient chargés une minute de plus, par exemple.
Portée d’apparition
Les créatures peuvent apparaître à certaines distances des joueurs. Nous allons réduire légèrement cette portée pour éviter les problèmes d’apparition des créatures. Ce paramètre est très important, car certains paramètres liés à leur apparition ont déjà été expliqués plus haut.
Modifie le paramètre suivant sous world-settings dans spigot.yml :
mob-spawn-range: 3 #Standard: 4
Portée d’activation des entités
Nous définissons ici à partir de quelle distance les entités — c’est-à-dire les animaux et les monstres — sont activées. Cela détermine, par exemple, si les animaux peuvent se déplacer ou si les monstres peuvent repérer les joueurs. Par défaut, cette fonction est activée pour toutes les créatures, mais en quelque sorte en mode veille. En veille, elles peuvent toujours se déplacer et repérer les joueurs, mais beaucoup plus lentement, par exemple, ce qui évite au serveur de devoir mobiliser trop de ressources.
Tu dois aussi modifier ces paramètres sous entity-activation-range dans spigot.yml. Nous te conseillons les valeurs suivantes :
animals: 6 #Standard: 32
monsters: 16 #Standard: 32
misc: 2 #Standard: 16
water: 6 #Standard: 6
tick-inactive-villagers: true #Standard: true
Optimisation des entonnoirs
Les entonnoirs sont un élément très important de Minecraft. Mais pour les serveurs, ils sont un véritable poison ! Pour chaque entonnoir placé, le serveur doit vérifier 20 fois par seconde si un objet peut être ramassé. Le transfert d’objets d’un entonnoir à un autre ou vers un coffre consomme aussi de précieuses ressources !
Pour améliorer un peu les choses, nous augmentons les intervalles auxquels le serveur effectue ces actions. Avec les valeurs utilisées ici, l’action est exécutée et vérifiée toutes les 3 secondes. Les taux de transfert ne changent pas. En revanche, les horloges de redstone construites avec des entonnoirs risquent de ne plus fonctionner correctement.
Pour cela, modifie les valeurs suivantes dans spigot.yml :
hopper-transfer: 24 #Standard: 8
hopper-check: 24 #Standard: 8
hopper-amount: 3 #Standard: 1
Collisions
Depuis la version 1.9 de Minecraft, les collisions empêchent, par exemple, un joueur de se tenir à l’intérieur d’un autre. Nous définissons ici la fréquence à laquelle les entités peuvent entrer en collision. Cela peut parfois beaucoup solliciter le serveur, notamment dans les fermes à créatures où de nombreux monstres sont regroupés dans un espace restreint.
Pour modifier ce paramètre, change la valeur suivante dans spigot.yml :
max-entity-collisions: 1 #Standard: 8
Les collisions n’ayant pas de véritable effet sur les créatures, tu peux réduire cette valeur. Elle ne s’applique pas aux joueurs, uniquement aux créatures !
Rayon de fusion
Le rayon de fusion détermine quels objets et orbes d’expérience sont regroupés. Le serveur a ainsi moins d’entités à traiter. Sur les serveurs où de nombreux objets jonchent le sol, augmenter ce rayon peut améliorer l’expérience des joueurs. Là encore, cherche le bon équilibre : si le serveur doit vérifier une zone plus grande, il consommera davantage de ressources et risque de provoquer des lags !
Pour modifier ces paramètres, change les valeurs suivantes sous merge-radius dans spigot.yml :
item: 4.0 #Standard: 2.5
exp: 6.0 #Standard: 3.0
Infos
Ne règle pas ces valeurs au-dessus de 8, au risque de provoquer les lags mentionnés ci-dessus !
Paper Spigot
Infos
Depuis Paper 1.19, il n’existe plus de fichier paper.yml unique. L’ancien fichier a été divisé en plusieurs fichiers dans le dossier config : paper-global.yml (paramètres à l’échelle du serveur) et paper-world-defaults.yml (valeurs par défaut pour tous les mondes, remplaçables pour chaque monde dans son propre fichier paper-world.yml). Les fichiers bukkit.yml et spigot.yml ne sont pas concernés et restent utilisés de la même manière. Comme Paper modifie de temps à autre certains noms de paramètres et chemins, consulte les commentaires du fichier de configuration concerné ou la documentation officielle de Paper en cas de différence.
Distance d’affichage
Réduire la distance d’affichage est une mesure très courante. La distance par défaut est de 10 chunks, mais de nombreux joueurs en utilisent beaucoup moins, par exemple 6 à 8. Certains vont trop loin et la règlent, par exemple, sur 32. Le serveur doit alors charger et traiter tous ces chunks, ce qui lui coûte beaucoup de ressources.
Sur un serveur Spigot (Paper), tu peux modifier la distance d’affichage dans la configuration spigot.yml, en changeant la valeur view-distance. Pour ne pas trop limiter l’expérience de jeu, nous te conseillons de régler cette valeur sur 5 ou 6, ce qui peut réduire la charge du serveur jusqu’à 50 %.
Infos
Selon tes préférences, tu peux aussi régler cette valeur sur 4. Cela peut notamment aider à réduire les lags si tu gères des serveurs de mondes de farm sous la version 1.13 ou une version ultérieure.
Compression des données
Un échange constant a lieu entre le serveur et les joueurs qui y sont connectés. Les déplacements des joueurs sont envoyés au serveur, qui les transmet à son tour aux autres joueurs. Les actions des joueurs et les événements du monde, comme les explosions, font également partie des données régulièrement transférées.
Pour rendre ces échanges plus efficaces, tu peux doubler la taille des données compressées. Le serveur n’aura alors besoin que de 50 % des ressources nécessaires pour échanger les mêmes données avec les joueurs. Pour cela, modifie la valeur network-compression-threshold dans la configuration server.properties. Nous te conseillons de la régler sur 512. Nous avons également consacré une page de notre guide à ce sujet, que tu trouveras ici.
Limites d’apparition
Cette étape consiste à réduire légèrement le taux d’apparition général des créatures sur le serveur. La différence avec les valeurs par défaut est à peine perceptible. Il peut toutefois arriver que certaines fermes à créatures ne fonctionnent pas comme prévu.
Pour modifier ces paramètres, édite le fichier de configuration bukkit.yml. Change les valeurs suivantes sous spawn-limits :
monsters: 50 #Standard: 70
animals: 10 #Standard: 15
water-animals: 3 #Standard: 5
ambient: 4 #Standard: 15
Infos
Tu peux bien sûr ajuster ces valeurs toi-même si tu le souhaites. Sinon, les valeurs ci-dessus constituent un très bon compromis. Sur un serveur Paper Spigot, tu peux aussi définir ces mêmes valeurs, qui seront prioritaires, sous entities.spawning.spawn-limits dans paper-world-defaults.yml.
Pour améliorer encore l’apparition des créatures, modifie également la valeur monster-spawns dans l’entrée ticks-per du fichier bukkit.yml :
monster-spawns: 2 #Standard: 1
En cas de problème général avec les monstres, par exemple si tu le constates dans le rapport de timing, tu peux augmenter la valeur jusqu’à 5. Observe alors le comportement du serveur avec chaque valeur pour trouver celle qui lui convient le mieux.
Traitement des chunks
Minecraft utilise ce qu’on appelle des chunks. Un chunk est composé de 16 x 16 blocs regroupés qui permettent au client de représenter visuellement le monde. Le serveur travaille donc uniquement avec des chunks et charge en RAM ceux dont il a besoin. Plus le serveur charge et traite de chunks en continu, plus il doit leur consacrer de ressources, ce qui peut finir par le mettre à genoux.
Avec les paramètres par défaut, les serveurs ne déchargent jamais les chunks chargés. La RAM peut donc être fortement sollicitée et une quantité énorme de mémoire peut être nécessaire. Les performances du serveur s’en trouvent malheureusement fortement réduites, car il doit traiter toujours plus de données.
Pour que le serveur ne charge que les chunks dont il a besoin à ce moment-là, tu peux modifier l’option suivante sous chunk-gc dans le fichier bukkit.yml :
period-in-ticks: 300 #Standard: 600
Infos
L’ancienne valeur supplémentaire load-threshold n’existe plus dans les versions actuelles de Paper, Spigot et Bukkit. Paper limite de toute façon period-in-ticks à un maximum de 20 ticks (1 seconde) côté serveur. Une valeur plus élevée n’a donc pratiquement plus aucun effet sur un serveur basé sur Paper (par exemple Paper Spigot).
L’option period-in-ticks détermine à quels intervalles, en secondes, les chunks sont déchargés. Tu peux réduire davantage cette valeur si tu le souhaites, mais attention : cela peut entraîner un effet indésirable, une boucle.
Dans ce cas, un chunk serait déchargé alors qu’il serait de nouveau nécessaire peu après. Le serveur devrait alors consacrer à nouveau du temps et des ressources à son chargement. Le phénomène se répéterait, imposant au serveur une charge plus importante que si les chunks restaient chargés une minute de plus, par exemple.
Portée d’apparition
Les créatures peuvent apparaître à certaines distances des joueurs. Nous allons réduire légèrement cette portée pour éviter les problèmes d’apparition des créatures. Ce paramètre est très important, car certains paramètres liés à leur apparition ont déjà été expliqués plus haut.
Modifie le paramètre suivant sous world-settings dans spigot.yml :
mob-spawn-range: 3 #Standard: 4
Générateurs de monstres
Les générateurs de monstres sont très utilisés, parfois en grand nombre, notamment sur les serveurs CityBuild. Ils produisent alors de plus en plus de créatures, ce qui peut entraîner de nombreux problèmes.
Ce paramètre ajuste légèrement leur comportement afin que le serveur active les générateurs à intervalles rapprochés. Pour cela, modifie la valeur suivante sous tick-rates dans paper-world-defaults.yml :
mob-spawner: 3 #Standard: 1
Infos
La valeur utilisée ci-dessus ne modifie pas trop le comportement et a peu d’impact sur l’expérience de jeu.
Portée d’activation des entités
Nous définissons ici à partir de quelle distance les entités — c’est-à-dire les animaux et les monstres — sont activées. Cela détermine, par exemple, si les animaux peuvent se déplacer ou si les monstres peuvent repérer les joueurs. Par défaut, cette fonction est activée pour toutes les créatures, mais en quelque sorte en mode veille. En veille, elles peuvent toujours se déplacer et repérer les joueurs, mais beaucoup plus lentement, par exemple, ce qui évite au serveur de devoir mobiliser trop de ressources.
Tu dois aussi modifier ces paramètres sous entity-activation-range dans spigot.yml. Nous te conseillons les valeurs suivantes :
animals: 6 #Standard: 32
monsters: 16 #Standard: 32
misc: 2 #Standard: 16
water: 6 #Standard: 6
tick-inactive-villagers: true #Standard: true
Optimisation des entonnoirs
Les entonnoirs sont un élément très important de Minecraft. Mais pour les serveurs, ils sont un véritable poison ! Pour chaque entonnoir placé, le serveur doit vérifier 20 fois par seconde si un objet peut être ramassé. Le transfert d’objets d’un entonnoir à un autre ou vers un coffre consomme aussi de précieuses ressources !
Pour améliorer un peu les choses, nous augmentons les intervalles auxquels le serveur effectue ces actions. Avec les valeurs utilisées ici, l’action est exécutée et vérifiée toutes les 3 secondes. Les taux de transfert ne changent pas. En revanche, les horloges de redstone construites avec des entonnoirs risquent de ne plus fonctionner correctement.
Pour cela, modifie les valeurs suivantes dans spigot.yml :
hopper-transfer: 24 #Standard: 8
hopper-check: 24 #Standard: 8
hopper-amount: 3 #Standard: 1
Collisions
Depuis la version 1.9 de Minecraft, les collisions empêchent, par exemple, un joueur de se tenir à l’intérieur d’un autre. Nous définissons ici la fréquence à laquelle les entités peuvent entrer en collision. Cela peut parfois beaucoup solliciter le serveur, notamment dans les fermes à créatures où de nombreux monstres sont regroupés dans un espace restreint.
Sur un serveur Paper Spigot, cette valeur ne se trouve plus dans spigot.yml, mais sous collisions dans paper-world-defaults.yml :
max-entity-collisions: 1 #Standard: 8
Les collisions n’ayant pas de véritable effet sur les créatures, tu peux réduire cette valeur. Elle ne s’applique pas aux joueurs, uniquement aux créatures !
Rayon de fusion
Le rayon de fusion détermine quels objets et orbes d’expérience sont regroupés. Le serveur a ainsi moins d’entités à traiter. Sur les serveurs où de nombreux objets jonchent le sol, augmenter ce rayon peut améliorer l’expérience des joueurs. Là encore, cherche le bon équilibre : si le serveur doit vérifier une zone plus grande, il consommera davantage de ressources et risque de provoquer des lags !
Pour modifier ces paramètres, change les valeurs suivantes sous merge-radius dans spigot.yml :
item: 4.0 #Standard: 2.5
exp: 6.0 #Standard: 3.0
Infos
Ne règle pas ces valeurs au-dessus de 8, au risque de provoquer les lags mentionnés ci-dessus !
Explosions
De nombreux éléments des serveurs de jeu Minecraft ont été reprogrammés dans Paper Spigot pour améliorer le fonctionnement du serveur. C’est également le cas des explosions ! Le logiciel les gère ainsi plus efficacement, ce qui permet d’éviter les gros lags sur le serveur.
Pour cela, modifie la valeur suivante sous environment dans paper-world-defaults.yml :
optimize-explosions: true #Standard: false
Coffres
Les coffres offrent aussi une petite possibilité d’optimisation ! Lorsqu’un chat est assis sur un coffre, il est impossible de l’ouvrir. Pour vérifier si c’est le cas, le serveur doit parcourir toutes les créatures dans un certain rayon et déterminer si l’une d’elles est assise dessus. Cette vérification, qui se produit à chaque ouverture de coffre, prend malheureusement beaucoup de temps !
Tu peux facilement désactiver cette option en modifiant la valeur suivante sous entities.behavior dans paper-world-defaults.yml :
Les inventaires sont très utilisés, mais ils ne se limitent pas aux espaces de stockage des joueurs. Un coffre ou une table de craft est aussi un inventaire. Grâce à cette modification, tu peux accorder un petit répit au serveur sans que personne ne s’en aperçoive ! Elle définit simplement le nombre de ticks qui s’écoulent avant que le serveur actualise chaque inventaire.
Pour cela, modifie la valeur suivante sous tick-rates dans paper-world-defaults.yml :
container-update: 3 #Standard: 1
Infos
Ne règle pas cette valeur au-dessus de 5, sinon l’inventaire risque de présenter des bugs ! Dans les modes de jeu comme SurvivalGames, où tous les joueurs veulent accéder aux coffres du milieu pour récupérer les meilleurs objets, ne modifie pas cette valeur et laisse-la sur 1.
Enregistrement des données des chunks
Lorsqu’un chunk est modifié, les changements ne sont pas immédiatement écrits sur le disque : ils sont d’abord chargés en RAM. Malgré cela, les changements sont enregistrés très fréquemment, ce qui peut parfois provoquer d’importants lags, surtout lorsque le serveur doit sauvegarder de nombreuses modifications.
Cette modification réduit le nombre maximal de chunks pouvant être enregistrés au cours d’une même opération de sauvegarde. En contrepartie, la RAM peut être davantage sollicitée, car les changements y restent plus longtemps !
Effectue la modification suivante sous chunks dans paper-world-defaults.yml :
max-auto-save-chunks-per-tick: 10 #Standard: 24
Redstone
La redstone est souvent utilisée dans des circuits parfois extrêmement complexes. Sur les serveurs publics, elle constitue parfois le point faible de près de 90 % des serveurs, car elle peut provoquer d’importants lags. Nous allons utiliser une méthode de traitement alternative de Paper Spigot, qui rend la redstone presque inoffensive tout en conservant les mêmes fonctionnalités que dans Vanilla !
Pour cela, modifie le paramètre suivant sous misc dans paper-world-defaults.yml :
En plus de VANILLA, tu peux choisir EIGENCRAFT ou ALTERNATE_CURRENT. Selon Paper, ALTERNATE_CURRENT est actuellement l’option la plus rapide et celle qui s’éloigne le moins du comportement de Vanilla.
Infos
Attention ! Dans certaines situations, cette option peut modifier considérablement le comportement de la redstone !
Hébergement de serveurs dès 2,49 € / mois, mise en ligne immédiate, protection DDoS incluse.
Source préférée sur Google
