Le carnet de l’atelier · N° 01
Lags, abeilles
& engrenages.
Le point sur les lags de TeaRoomCraft V4 : les tests effectués, ce qu’on a constaté et les améliorations envisagées.
01 / Le mot de l’atelier
Comment se porte le serveur ?
Oyez, habitantes et habitants de TeaRoomCraft ! 🍂 J’ai passé pas mal de temps à analyser les lags et à tester des solutions. Voici un bilan pour vous expliquer ce qui a été fait et pourquoi certains problèmes restent à résoudre.
Oui, il y a des ralentissements, et parfois des crashs. Ils peuvent vraiment gêner le jeu. Malgré cela, je trouve que le serveur fonctionne plutôt bien dans l’ensemble, compte tenu des machines, des créatures et des constructions mobiles du pack.
Les mesures ont identifié plusieurs sources de charge : les créatures, les zones du monde chargées, les actions répétées des datapacks, les machines et la physique. Leur importance varie d’un relevé à l’autre ; on ne peut pas attribuer tous les lags à un seul mod.
Les TPS, c’est le rythme de la simulation du serveur : la cible est de 20 mises à jour par seconde. Quand ce rythme chute, le monde ralentit, même si votre jeu affiche beaucoup d’images par seconde. Un lag, une déconnexion et un crash ne sont donc pas forcément le même problème.
02 / Les vérifications et les essais
Ce qui a été fait.
L’enquête a combiné l’analyse des journaux du serveur, des mesures pendant le jeu et des essais sur un serveur séparé, créé depuis une sauvegarde.
Observer les ralentissements
Lecture des logs, des déconnexions et des rapports de crash. Un enregistrement Java de deux minutes, puis des mesures avec Spark ont permis d’identifier les calculs qui occupaient le serveur.
Vérifier la machine et Crafty
Contrôle du processeur, de la mémoire et du disque. Aucun bridage trouvé pendant l’audit ; environ 20 Gio de RAM étaient encore disponibles. En revanche, le fil d’exécution principal de Minecraft utilisait presque toute la capacité d’un cœur du processeur. Les autres cœurs disponibles ne peuvent pas automatiquement prendre en charge ce travail.
Compter les entités et examiner les zones chargées
Comptage des abeilles, des autres animaux et des villageois. Inspection des données sauvegardées, des configurations et des actions que les datapacks exécutent régulièrement.
Comparer avec et sans Async
Sur le serveur de test : mêmes 80 chunks temporairement chargés et 47 villageois, puis essais avec un joueur. Async a bien réparti une partie du travail sur trois threads supplémentaires.
Tester les chargements lors des téléportations
Deux sessions d’environ dix minutes, avec 39 commandes
/backchacune, avec puis sans Async. Les téléportations répétées ont permis de mesurer les ralentissements au chargement des zones et le temps nécessaire pour retrouver un rythme proche de 20 TPS.Essayer sur la durée, puis revenir en arrière
Après le test à trois threads, essai d’Async à dix threads en production. D’après mon observation en jeu, le serveur et les TPS étaient plutôt stables pendant cette période, jusqu’au crash du 28 septembre. L’analyse a ensuite pointé une interaction Async/Sable, et Async a été retiré.
Ouvrir le carnet de mesures
Sans joueur : les deux configurations tenaient 20 TPS après le chargement. Temps de calcul médian par tick relevé : 20,5 ms sans Async et 17,2 ms avec. Le nombre d’entités et le moment des mesures différaient ; cet écart ne suffit donc pas à calculer un gain fiable.
Téléportations avec Async : les relevés de TPS sur une minute variaient de 16,15 à 20, avec huit alertes de retard et un retour vers 20 TPS. Aucun crash serveur pendant cette session.
Téléportations sans Async : pendant l’activité du joueur, les relevés de TPS sur une minute variaient de 19,55 à 20, avec une alerte de retard. Un crash du jeu côté joueur a interrompu le parcours ; le serveur est resté actif. La cause de ce crash client n’a pas été établie.
Les limites de la comparaison : le rythme des téléportations différait, une session a été interrompue et le monde avait évolué entre les essais. Le serveur de test disposait aussi de ressources limitées. Ces résultats décrivent ces deux sessions ; ils ne suffisent pas à prévoir les performances pendant une soirée avec plusieurs joueurs.
Sur le serveur principal, avant Async : les mesures du 27 septembre ont enregistré des périodes autour de 7–8 TPS, bien en dessous de la cible de 20. Ces chiffres confirment les ralentissements de cette soirée. Ils ne décrivent pas la période de production avec Async et ne sont pas directement comparables aux essais sur le serveur de test.
03 / Sable et Aeronautics
À quoi sert Sable dans le pack ?
Sable est une bibliothèque de physique. Elle permet de déplacer des ensembles de blocs tout en les gardant interactifs. Une construction assemblée peut bouger, tourner et réagir aux collisions, avec des blocs et des entités qui continuent à fonctionner à bord. Son moteur physique s’appuie sur Rapier. Présentation officielle de Sable ↗
Dans notre pack, Create Aeronautics dépend de Sable et de Create. Aeronautics apporte les outils pour construire des engins volants et terrestres ; Sable fournit la base qui rend leur mouvement possible. Le retirer remettrait donc en cause toute cette partie de l’expérience. Présentation officielle d’Aeronautics ↗
Sable modifie profondément le fonctionnement de Minecraft. Son équipe signale elle-même des risques de conflits avec d’autres mods. Un mod d’optimisation peut modifier les mêmes calculs, notamment les collisions ou le traitement des créatures : il faut alors vérifier que les deux fonctionnent correctement ensemble.
C’est une contrainte importante pour les optimisations du pack. Cela ne suffit toutefois pas à attribuer tous les ralentissements à Sable.
Je ne prévois pas de retirer Aeronautics. Construire nos véhicules et nos dirigeables faisait partie de l’expérience annoncée pour TeaRoomCraft V4. Je souhaite conserver cette possibilité tout en améliorant les performances du serveur.
Un retrait de Sable et d’Aeronautics demanderait aussi de vérifier ce que deviennent les constructions existantes. Aeronautics ajoute ses propres contenus, et Sable enregistre les constructions mobiles dans un stockage spécifique. Leur retrait pourrait donc affecter l’accès à ces véhicules et aux contenus associés. Voir le stockage des constructions dans le code de Sable ↗
Les conséquences exactes sur notre monde restent inconnues. Aucun essai de retrait de ces deux mods n’a été réalisé. Pour les connaître, il faudrait tester sur une copie sauvegardée du monde, puis vérifier le chargement du pack et les constructions. Je ne peux donc pas garantir un retrait sans problème, mais je n’ai pas non plus de preuve qu’il rendrait le serveur inutilisable.
04 / L’essai d’Async en production
Un serveur plus régulier, jusqu’au crash.
Une fois Async mis en production, le serveur était plutôt stable, et les TPS aussi. Je ressentais une vraie amélioration de la régularité en jeu. Ça se passait plutôt bien jusqu’au crash, dont les traces pointent vers un conflit entre Async et Sable.
— Mon observation en production, Nyx
Async permet de traiter une partie des entités en parallèle. Les mesures sur le serveur de test ont confirmé qu’il répartissait effectivement du travail sur plusieurs threads. Mon retour sur la stabilité concerne ensuite son utilisation sur le serveur principal ; les essais comparatifs ne permettent pas de chiffrer précisément l’amélioration que j’y ai observée.
Le 28 septembre, le serveur s’est bloqué assez longtemps pour que son système de surveillance l’arrête. Le rapport montre que le traitement principal attendait la fin de calculs Async. Certains de ces calculs attendaient eux-mêmes le chargement de zones du monde lors de collisions gérées par Sable.
Un conflit entre Async et Sable est donc fortement suspecté. D’autres signalements décrivent des blocages avec ces mods : Async #171 et Sable #1447. Les symptômes concordent, mais la cause exacte de notre crash n’a pas été reproduite dans un test isolant ces mods.
Exclure les entités de Create du traitement parallèle ne protège pas forcément contre ce problème : les déplacements d’autres créatures peuvent aussi faire appel aux collisions de Sable. J’ai donc fait retirer Async après le crash. La fluidité observée avant l’incident était encourageante, mais elle ne suffisait pas à justifier de conserver cette configuration.
J’ai ouvert le signalement #205 sur leur GitHub, avec le rapport de crash, les journaux du serveur, la configuration et les versions des mods. Le dossier décrit le blocage observé entre les calculs d’Async et les collisions de Sable.
Pour ce problème de compatibilité, la balle est maintenant dans leur camp : j’attends leur analyse et leurs indications sur un éventuel correctif ou une version à tester. Au 30 septembre, le signalement est ouvert et n’a pas encore reçu de réponse. Toute nouvelle version proposée devra être vérifiée sur le serveur de test avant d’envisager un retour en production.
05 / Realistic Bees et Productive Bees
D’où vient ce surplus d’abeilles ?
Un relevé du 25 septembre a compté 932 abeilles ordinaires chargées dans le Nether. Un second comptage trouvait 806 abeilles ordinaires et 47 abeilles Productive Bees. Le nombre d’entités comptées peut changer avec les zones chargées ; cette différence ne prouve pas que des abeilles ont disparu.
Realistic Bees peut expliquer une partie de cette surpopulation. Avec le réglage examiné, le mod ajoutait neuf abeilles ordinaires lorsqu’une abeille remplissait ses conditions d’apparition. L’inspection du code installé a montré que certaines abeilles Productive Bees pouvaient aussi déclencher cet ajout. Les nouvelles abeilles reçoivent un marqueur qui les empêche de produire à leur tour neuf copies.
Le paramètre extraBeeSpawnsPerBee de Realistic Bees peut passer de 9 à 0. Cette valeur désactive les ajouts automatiques sans nécessiter de retirer Productive Bees. Voir les paramètres officiels ↗
Ce réglage reste une correction envisagée dans ce bilan. Il ne retire pas les abeilles déjà présentes. Il faudrait donc s’occuper séparément du surplus existant, en préservant les élevages des joueurs.
Les calculs liés aux abeilles, notamment leurs déplacements, occupaient une part notable du temps de calcul dans un relevé. Cette part était plus faible dans d’autres mesures. De plus, les lags existaient avant l’arrivée de Productive Bees : réduire le nombre d’abeilles ne suffira pas forcément à résoudre tous les ralentissements.
Le conseil du village rappelle aux abeilles que le Nether n’a pas été classé « rucher communal ». 🐝
06 / La compatibilité des mods
Pourquoi ajouter un mod demande des tests.
Plusieurs ajouts ont déjà posé des problèmes. Copycats+ a été retiré après un incident de compatibilité. Il a fallu choisir des versions de Sodium et Iris compatibles entre elles et avec les exigences de Sable et des autres mods. Des autorisations d’accès aux fichiers ont également dû être corrigées, notamment pour que Moonlight puisse écrire dans son cache.
Ce sont des problèmes différents : un conflit de versions, une erreur d’accès à un fichier et un blocage de simulation n’appellent pas la même solution. Tous ne viennent pas de Sable, et tous ne sont pas apparus avec Async.
D’autres solutions pour répartir le travail entre plusieurs cœurs ont été examinées. Folia ne permet pas de reprendre directement notre pack NeoForge. Répartir les dimensions sur des threads séparés est une autre possibilité étudiée, mais elle n’a pas été testée sur notre serveur.
Un mod peut améliorer les performances tout en provoquant un conflit avec un autre. Le serveur de test sert à repérer ces problèmes avant un éventuel ajout en production. L’essai d’Async montre aussi que des tests courts ne suffisent pas à détecter tous les incidents.
07 / Les prochaines pistes
Ce qu’il reste à améliorer.
Mon bilan reste positif dans l’ensemble, mais les ralentissements et les crashs demandent encore du travail. Les essais ont permis d’identifier plusieurs sources de charge et un conflit probable entre Async et Sable. Ils n’ont pas encore apporté de solution à tous les problèmes.
Les pistes à examiner sont la limitation des ajouts automatiques d’abeilles, les zones concentrant beaucoup de créatures et les optimisations compatibles avec le pack. Il faudra mesurer l’effet des changements retenus pendant de vraies sessions de jeu.
Un souci en jeu ?
Sur Discord, indiquez l’heure, ce que vous faisiez, la zone concernée et si le problème touchait plusieurs personnes. Précisez s’il s’agissait d’un ralentissement, d’une déconnexion ou d’une fermeture du jeu. Ces petits détails aident beaucoup à retrouver les bonnes traces.
Merci pour votre patience, vos retours et toutes les histoires que vous faites vivre ici. 🍵
À bientôt
sur TeaRoomCraft.
Nyx