Principaux coupables de performance

Les fuites de mémoire représentent la cause la plus fréquente de plantage de serveur. Les objets qui ne sont pas correctement éliminés par le ramasse-miettes s'accumulent au fil du temps jusqu'à ce que le serveur dépasse sa RAM allouée et soit arrêté. Recherchez les écouteurs d'événements qui ne sont jamais supprimés et les collections statiques qui croissent indéfiniment.

Un test utile consiste à vérifier si l'utilisation de la mémoire évolue de manière linéaire avec le nombre de joueurs. Si elle augmente alors que le nombre de joueurs reste stable, vous avez une fuite et non un problème de capacité.

Les opérations gourmandes en processeur bloquent la boucle de jeu principale et créent des pics de décalage. Les calculs physiques, les algorithmes de recherche de chemin et les routines d'IA complexes devraient s'exécuter sur des threads séparés ou utiliser des techniques de découpage temporel pour répartir le travail sur plusieurs images. Surveillez également la contention des threads, car une tâche bloquée dans le graphe ressemble beaucoup à une tâche coûteuse vue de l'extérieur.

Une mise en garde lors de la lecture des graphiques de processeur : les moteurs de jeu ont tendance à faire des pics lors de l'initialisation du serveur. C'est normal. Si l'utilisation ne s'est pas stabilisée deux à trois minutes après le démarrage, le problème vient de votre code de serveur ou de vos ressources allouées.

Goulots d'étranglement du réseau

Un trafic réseau excessif sature la bande passante du serveur et provoque des effets de retour en arrière (rubber-banding). Envoyer la position des joueurs 60 fois par seconde fonctionne très bien avec 10 joueurs, mais échoue avec 100. Implémentez la compression delta et n'envoyez que les données modifiées, en gardant la réplication complète de l'instantané comme solution de secours pour la récupération de désynchronisation.

Deux victoires plus faciles se trouvent généralement juste à côté. Réduisez la taille des types de données sur les propriétés répliquées pour shrinker la taille des paquets, et regroupez les actions qui ne peuvent jamais se produire séparément en un seul RPC paramétré au lieu d'en lancer plusieurs.

Une mauvaise configuration du taux de rafraîchissement (tick rate) crée des expériences de jeu incohérentes. Les serveurs fonctionnant à 20 Hz semblent lents par rapport à 64 Hz, mais des taux plus élevés consomment plus de processeur et génèrent plus d'opérations de messagerie. Équilibrez le taux de rafraîchissement par rapport à la capacité du serveur et au nombre de joueurs.

Si le décalage persiste après que le code réseau a été nettoyé, la distance restante est physique. Pour en savoir plus sur cette moitié du problème, lisez le guide d'Edgegap sur pourquoi plus de localisations réduisent la latence.

Profilez avant de deviner

La plupart des équipes optimisent par intuition. Le profilage remplace la conjecture par un chiffre.

Le profilage de serveur est le processus de collecte et d'analyse des données de performance d'un serveur dédié pour comprendre comment il consomme le processeur, la mémoire et la bande passante sous une charge multijoueur réelle. Dans Unreal Engine, cela signifie deux outils travaillant ensemble. Unreal Trace Server est le collecteur, un service léger qui rassemble les données de trace émises au moment de l'exécution. Unreal Insights est le visualiseur, où vous analysez l'exécution du processeur, les allocations de mémoire, le chargement des ressources et le trafic de réplication.

Les questions qui méritent d'être résolues avant de modifier le moindre code :

• Quels acteurs consomment le plus de mémoire, et quelles conditions mènent à un plantage par manque de mémoire ?

• Quelles fonctions ou fonctionnalités consomment des cycles de processeur, et le facteur déterminant est-il le nombre de joueurs, le taux de rafraîchissement, l'IA, la physique ou la réplication ?

• Quelles fonctionnalités dominent le coût par tick, et comment la modification du taux de rafraîchissement affecte-t-elle la stabilité de la simulation et l'utilisation du réseau ?

• Qu'est-ce qui produit de la gigue (jitter), des pics de latence ou une désynchronisation côté serveur ?

Vous pouvez enregistrer les traces sur le disque avec -tracefile et les analyser hors ligne, ou les diffuser en direct depuis un déploiement en cours d'exécution en exposant le port interne 1981 en UDP pendant les tests de développement. Le guide complet d'Edgegap se trouve dans Comment analyser & optimiser les serveurs de jeu d'Unreal Engine avec le profilage de serveur.

Une fois que la trace vous indique où se situe le coût, la solution est généralement un paramètre de build auquel vous n'avez pas encore touché. Edgegap propose des listes de contrôle spécifiques aux moteurs pour cette étape : Unreal, Unity et Godot.

Surveillance des ressources

Suivez en continu l'utilisation de la mémoire, l'utilisation du processeur et le débit réseau pendant les sessions de jeu. Les pics soudains indiquent des opportunités d'optimisation tandis que les augmentations progressives suggèrent des fuites de mémoire.

Les métriques de conteneur sur la page de détails du déploiement couvrent ces trois aspects. Les métriques d'historique calculent une moyenne sur une fenêtre d'une minute pour le niveau gratuit ; ajouter une carte à un compte gratuit déverrouille les métriques brutes et non agrégées à un intervalle de rapport d'une seconde, qui est la résolution dont vous avez besoin pour capturer un pic qui dure trois images.

Chaque déploiement reçoit également un identifiant unique. C'est ce qui vous permet de lier le rapport d'un testeur indiquant « ça a ramé à la fin de la deuxième manche » à la partie exacte et à la courbe de ressources exacte, en direct ou après coup.

Les journaux de conteneur vous permettent de suivre une trace d'exécution jusqu'au code incriminé, à condition de fournir les symboles de débogage avec votre build. Un avertissement important qui surprend souvent : les journaux de conteneur sont supprimés lorsqu'un déploiement s'arrête. Configurez un stockage de journaux S3 tiers avant d'en avoir besoin, et non après le plantage que vous vouliez analyser.

Les requêtes de base de données deviennent souvent des goulots d'étranglement de performance à mesure que le nombre de joueurs augmente. Mettez en cache les données fréquemment consultées en mémoire et utilisez le pooling de connexions pour réduire la charge de travail de la base de données. Envisagez des réplicas de lecture pour les opérations lourdes en données.

Optimisation de l'infrastructure

Le matériel serveur a un impact direct sur les capacités de performance. Une RAM insuffisante oblige le système d'exploitation à échanger de la mémoire sur le disque, créant de graves pics de décalage. Un nombre insuffisant de cœurs de processeur limite la capacité d'accueil de joueurs simultanés.

La plateforme d'orchestration d'Edgegap provisionne des instances à la demande à travers plus de 615 localisations et signale en temps réel les métriques de processeur, de mémoire et de réseau par déploiement. Les plantages et les arrêts pour manque de mémoire (OOM) déclenchent des tentatives de redémarrage automatique basées sur votre politique de redémarrage de processus, de sorte qu'une défaillance reste confinée à un seul match plutôt que d'entraîner une instance partagée avec elle. L'état du serveur est tout de même perdu lors du redémarrage, il convient donc de décider à l'avance ce que votre session peut reconstruire et ce qu'elle ne peut pas.

Les avantages de la réduction de l'utilisation des ressources se font sentir des deux côtés. Une densité de serveurs plus élevée signifie des coûts de calcul inférieurs, et des tailles d'instances plus petites signifient que vous pouvez vous offrir le taux de rafraîchissement que vous souhaitiez réellement. Pour un aperçu plus large de la couche d'orchestration, Edgegap propose une comparaison entre l'orchestration juste-à-temps et l'orchestration traditionnelle.

Stratégies de débogage

Activez la journalisation détaillée pour l'analyse des plantages sans affecter les performances. Écrivez les journaux de manière asynchrone et effectuez une rotation des fichiers pour éviter les problèmes d'espace disque. Incluez des horodatages, le nombre de joueurs et l'utilisation des ressources dans les entrées de journal.

Reproduisez les problèmes dans des environnements contrôlés à l'aide d'outils de test de charge qui simulent un comportement de joueur réaliste. Les tests synthétiques révèlent les problèmes avant qu'ils n'affectent les vrais joueurs et offrent des conditions cohérentes pour le débogage.

La diffusion des ressources (asset streaming) et le chargement au moment de l'exécution méritent une attention particulière. Les pics d'E/S disque et le coût de sérialisation lors des opérations de réplication ou de sauvegarde apparaissent dans les graphiques de processeur et de réseau comme s'il s'agissait de problèmes logiques, ce qui pousse les équipes à optimiser le mauvais système.

Valider la correction

Une optimisation que vous ne pouvez pas mesurer est une conjecture avec des étapes supplémentaires. Créez deux variantes ou plus ciblant le problème spécifique, proposez-les à une petite sous-population à l'aide de la segmentation de votre backend, puis comparez les métriques normalisées et vérifiez si la différence est statistiquement significative avant de la déployer.

Ensuite, itérez. Les équipes qui maintiennent les serveurs stables à grande échelle ne sont pas celles qui ont fait un profilage une seule fois.