Comment améliorer les performances d'un serveur Rust

Ce qui affecte réellement les performances

Une performance constante est ce qui rassure vos joueurs sur le fait qu'ils ont un endroit sûr où jouer, où ils ne perdront pas un combat à cause du lag et ne se feront pas téléporter au bord d'une falaise. Il vaut la peine d'être précis sur son origine, car le temps passé sur la mauvaise chose est perdu.

Approximativement par ordre d'impact :

1. Plugins. Un seul plugin mal écrit peut dominer chaque tick du serveur.
2. Fréquence du CPU. Le plafond sous lequel tout le reste opère.
3. Nombre d'entités. En fin de cycle de wipe, c'est ce qui change sous vos pieds.
4. Opérations de sauvegarde. Sur un grand monde, perceptibles à chaque exécution.

Matériel : la fréquence plutôt que le nombre de cœurs

Vous constaterez des performances serveur nettement meilleures chez les hébergeurs utilisant des CPU plus rapides, cadencés au-delà de 3GHz. La raison est architecturale plutôt qu'accessoire : les fonctions principales d'Unity sont monothread, donc elles tournent sur un seul cœur et ne peuvent pas être réparties sur les autres. Un CPU 32 cœurs à 2.2GHz fera tourner un serveur Rust moins bien qu'un 8 cœurs à 4GHz.

Le nombre de cœurs n'est pas hors de propos. Des éléments comme l'IA des PNJ et des animaux, et d'autres objets liés à la map, peuvent être répartis sur plusieurs cœurs, c'est pourquoi les serveurs à forte population profitent réellement de cœurs supplémentaires. Un bon hébergeur devrait proposer l'option de plus de cœurs pour un serveur plus grand, et devrait déjà héberger Rust sur des CPU haute fréquence.

Plugins : le facteur le plus important

uMod est un addon de modding pour Rust qui permet aux serveurs d'exécuter des plugins développés en majorité par la communauté. Les performances du serveur ne sont pas affectées par des plugins bien écrits et activement maintenus.

Elles seront détruites par un mauvais plugin. Sans que vous vous en rendiez compte, un petit bout de code dans l'un de vos plugins pourrait dégrader sérieusement les performances de votre serveur, et rien dans la taille ou la simplicité apparente d'un plugin ne vous indique lequel. Même le plugin le plus petit et le plus léger en apparence peut causer le chaos, comme le confirmera tout propriétaire de serveur Rust ou développeur de plugins expérimenté.

Évitez de faire tourner trop de plugins. Le nombre lui-même a un coût, indépendamment de la qualité de chacun, et la réponse à un problème consiste plus souvent à retirer un plugin qu'à en ajouter un.

Optimiser les plugins que vous gardez

Certains plugins exposent des réglages de performance comme des timers et des intervalles. Ils sont généralement désactivés par défaut ou réglés prudemment. Consultez le fichier de configuration du plugin et activez-les, car un plugin qui sonde à chaque tick alors qu'il pourrait sonder toutes les trente secondes fait trente fois plus de travail que nécessaire.

Mesurer avant de changer quoi que ce soit

Deviner les problèmes de performance fait perdre du temps. Il y a deux mesures qui valent la peine d'être prises.

FPS serveur

C'est la fréquence d'images à laquelle le serveur fonctionne. Elle n'a aucune influence directe sur le FPS de vos joueurs, bien qu'un nombre élevé d'entités dans une zone affectera les deux. Surveillez-la via RCON avec la commande FPS.

Le plugin Performance Monitor

Le Performance Monitor pour uMod fournit des informations en temps réel sur l'utilisation mémoire, le temps de hook des plugins et d'autres délais qui affectent la performance du serveur. Il vous montrera quel plugin consomme le plus de temps sur un seul hook, ce qui transforme « le serveur rame » en un nom précis.

Les convars qui comptent

Chacune d'entre elles est un compromis plutôt que de la performance gratuite. Les gains sont réels, tout comme ce que vous sacrifiez.

batching.colliders "0"

Supprime le besoin pour le serveur de regrouper les entités en lots. C'est un gain de performance important : avec le batching activé, à chaque construction, le serveur doit dégrouper puis regrouper toutes les entités concernées.

La réserve : si votre serveur dépasse 265 000 entités, vous devrez le réactiver pour contourner la limite d'entités d'Unity. En fin de long cycle de wipe sur un serveur fréquenté, c'est un chiffre réel plutôt que théorique, donc cela vaut la peine d'être surveillé.

nav_disable "true"

Désactive le NAV mesh sur votre serveur. Le gain de performance est important. Le coût, c'est que les animaux et les PNJ arrêtent complètement de bouger.

Que ce soit acceptable dépend de votre serveur. Sur un serveur très orienté PvP où personne ne chasse le cerf, c'est presque gratuit. Sur un serveur PvE ou roleplay, cela retire une partie significative du jeu.

ai.think 0

Vous avez peut-être remarqué sur de gros serveurs que les animaux ne réagissent pas et ne ripostent pas. C'est ai.think réglé à 0. Cela a un effet positif significatif sur la performance, en particulier quand le nombre de joueurs est élevé et qu'ils sont souvent proches des animaux.

server.saveinterval "600"

Vous pouvez constater des chutes de FPS côté serveur lors des sauvegardes sur un serveur à forte densité d'entités. Augmenter la durée entre les sauvegardes limite cela au minimum.

Le compromis ici est le risque : un intervalle plus long signifie plus de progression perdue si le serveur plante entre deux sauvegardes. 600 secondes est un équilibre raisonnable, mais si votre serveur est instable pour d'autres raisons, ne traitez pas le symptôme en rendant les plantages plus coûteux.

fps.max

Contrôler le FPS de votre serveur est globalement une bonne idée, pour éviter que le serveur ne travaille plus dur que nécessaire sans aucun bénéfice pour vos joueurs. Facepunch a indiqué que les joueurs ne remarqueraient pas un serveur limité à 30 images par seconde. Il est fortement conseillé de régler fps.max sur un nombre entre 30 et 100.

Redémarrages

Des redémarrages quotidiens peuvent aider la performance sur les serveurs moddés. Les processus qui tournent longtemps accumulent de la pression mémoire, et les plugins qui fuient lentement sont suffisamment courants pour qu'un redémarrage planifié soit une assurance raisonnable.

Planifiez-les à une heure calme et annoncez-les. global.restart donne aux joueurs un avertissement de 300 secondes par intervalles de 5 secondes, ce qui laisse assez de temps pour se mettre en sécurité. Un redémarrage silencieux en plein raid vous fera perdre plus de joueurs que le gain de performance n'en rapporte.

Que faire, dans l'ordre

1. Mesurez d'abord

   Vérifiez le FPS serveur via RCON et lancez brièvement le Performance Monitor. Sans référence de départ, vous ne pouvez pas savoir si ce que vous avez fait a aidé.

2. Retirez le pire plugin

   Quel qu'il soit selon le monitor. C'est presque toujours le plus gros gain disponible, et c'est gratuit.

3. Réglez les plugins que vous gardez

   Timers et intervalles dans leurs fichiers de config, quand ils existent.

4. Appliquez les convars

   Commencez par batching.colliders "0", fps.max et server.saveinterval, qui ne vous coûtent rien que vos joueurs remarqueront. N'envisagez nav_disable et ai.think que si vous pouvez accepter une faune statique.

5. Mesurez à nouveau

   Mêmes outils, mêmes conditions, idéalement avec un nombre de joueurs similaire. Puis déchargez le monitor.

6. Examinez le matériel

   Si vous avez fait tout ce qui précède et que la performance reste mauvaise, le plafond, c'est le CPU, et aucune configuration ne permet de le dépasser.

Si vous en êtes à cette dernière étape, notre guide sur ce qu'il faut rechercher avant d'acheter un serveur Rust couvre les questions à poser à un hébergeur avant de migrer.