Test de charge
Les tests de charge simulent des joueurs simultanés sur votre infrastructure afin de découvrir où elle cède avant que de vrais joueurs ne le fassent. Ils répondent à des questions qu'aucune révision de code ne peut résoudre : à quel niveau de simultanéité votre architecture s'effondre-t-elle, quand l'allocation commence-t-elle à s'accumuler en file d'attente, et qu'est-ce qui échoue en premier. L'objectif est de trouver délibérément le point de rupture.
Aussi appelé
test de charge
,
Qu'est-ce que le test de charge et pourquoi un pic d'affluence est-il le test le plus difficile pour les jeux ?
Les tests de charge forment une famille de tests, chacun répondant à une question différente. La documentation de k6 en répertorie six (Grafana k6) :
Test | Ce qu'il vérifie | Ce à quoi cela ressemble pour un jeu |
|---|---|---|
Smoke (test de fumée) | Si les scripts et la configuration fonctionnent | Quelques parties, du début à la fin |
Charge moyenne | Comportement lors d'un trafic typique | Un pic quotidien normal |
Stress | Comportement au-dessus du trafic normal | Deux fois le pic attendu |
Spike (pic soudain) | Une augmentation soudaine du trafic | Le début d'un événement ou l'heure de lancement |
Soak (endurance) | Stabilité sur une longue période | Des heures ou des jours, pour détecter les fuites |
Breakpoint (point de rupture) | Là où cela cesse de fonctionner | Continuer à ajouter des parties jusqu'à ce que quelque chose échoue |
Cette page se concentre sur le test de type « spike » (pic soudain), qui est probablement le plus difficile des six pour un jeu multijoueur. Un afflux de joueurs se traduit par un afflux de parties, et chaque partie nécessite son propre serveur, démarré à la demande et conservé pendant des minutes ou des heures. Prenez 2 000 joueurs simultanés dans des parties de quatre : cela représente 500 serveurs fonctionnant en même temps. Si 20 nouvelles parties commencent chaque minute et que chacune dure environ 25 minutes, 500 serveurs sont en ligne au moment du pic. Un pic augmente le taux d'arrivée, de sorte que le système de matchmaking, les requêtes de serveurs et les notifications le ressentent tous au même instant.
Un pic n'est pas non plus instantané. Les joueurs arrivent par vagues, et créer mille serveurs en une seconde prouve surtout que les limites de requêtes vous opposeront un refus. Façonnez donc l'afflux de la même manière que se comporte le trafic réel :
Montez en charge de manière abrupte, mais pas instantanée. Commencez lentement, montez par paliers, puis stabilisez.
Ajoutez du caractère aléatoire. Ne créez pas de serveurs à des intervalles de secondes exactes, car les vraies parties se forment avec une variance naturelle.
Variez la durée des parties. Certaines se terminent rapidement et d'autres durent longtemps, de sorte que la capacité se libère de manière inégale.
Répartissez les joueurs. Les joueurs proviennent de plusieurs régions, ce qui influence l'endroit où les serveurs sont positionnés.
Maintenez la charge assez longtemps. Les rafales courtes masquent les problèmes qui n'apparaissent qu'après plusieurs heures.
Les cinq autres tests découlent de la même structure : il suffit de modifier la hauteur de la rampe de montée ou la durée du maintien.
Que doit couvrir un test de charge de jeu ?
Bien plus que le serveur de jeu. Un match passe par une chaîne, et le maillon le plus faible fixe la limite :
Étape | Ce qui peut casser | Ce qu'il faut surveiller |
|---|---|---|
Matchmaker | Les tickets s'accumulent, les groupes se forment lentement | Temps écoulé entre le ticket et le match |
Allocation | La demande de serveur est retardée ou refusée | Temps écoulé entre "match trouvé" et "serveur prêt", taux d'erreur |
Notification | Le backend manque le message "le serveur est prêt" | Notifications manquées ou dupliquées |
Backend et base de données | Requêtes lentes, connexions épuisées | Temps de requête, erreurs |
Serveur de jeu | Fuites de mémoire, dérive du tick rate sous la charge | Temps de tick, mémoire au fil des heures |
Nettoyage | Serveurs laissés actifs après le match | Serveurs résiduels |
Les fuites de mémoire, les requêtes de base de données lentes et un code réseau inefficace sont des constatations typiques, et aucune d'entre elles n'apparaît si le test demande uniquement à un serveur de démarrer.
Testez la chaîne que vous allez réellement utiliser. Un test qui contourne le matchmaker et appelle l'API d'allocation en boucle vérifie l'API, pas votre lancement. Le Matchmaker couvre la façon dont les vrais joueurs font la queue, et la scalabilité couvre la façon de dimensionner la cible.
Quel outil de test de charge devriez-vous utiliser pour un jeu ?
Trois outils open source couvrent la plupart des équipes, et le choix dépend principalement de la manière dont votre équipe préfère rédiger les tests :
Apache JMeter dispose d'une interface visuelle et de rapports intégrés, il convient donc aux équipes qui préfèrent créer des scénarios sans code. Il prend en charge, entre autres, HTTP et TCP, et peut être exécuté de manière distribuée.
k6 écrit les tests en JavaScript, ils résident donc dans le contrôle de version et s'exécutent dans un pipeline CI.
Locust écrit les tests en Python et peut être exécuté de manière distribuée sur plusieurs machines.
Tous trois sont performants pour une tâche : piloter la partie HTTP de votre infrastructure, comme les tickets de matchmaking, les requêtes serveur et les gestionnaires de webhooks. Aucun d'entre eux ne fait tourner votre jeu. Pour tester la connexion elle-même, vous avez besoin de bots clients, et c'est là que se situe la véritable décision. Le guide d'Edgegap traite cela comme optionnel mais précieux : les bots qui se connectent à chaque serveur prêt indiquent si un serveur qui se déclare "prêt" accepte les joueurs, et la solution de repli plus économique consiste à tester la connectivité réseau brute vers l'adresse et le port de chaque serveur (article 246). Les bots nécessitent du temps d'ingénierie, et un simple test de connectivité ne peut pas vous dire si le match se déroule correctement.
Comment exécuter le test et nettoyer ensuite ?
Commencez par un profil qui correspond à votre lancement, puis adaptez-le. Le guide d'Edgegap en propose trois, chacun comprenant une phase de montée en charge (ramp) suivie d'un maintien (hold) (article "How to run a Load Test for any Multiplayer Game") :
Profil | Joueurs simultanés | Joueurs par match | Nouveaux matchs par minute | Montée en charge, puis maintien |
|---|---|---|---|---|
Lancement indépendant | 200 | 2 | 5 | 10 minutes, puis 60 minutes |
Titre de taille moyenne | 2 000 | 4 | 20 | 20 minutes, puis 90 minutes |
Week-end de bêta | 10 000 | 6 | 50 | 30 minutes, puis 2 à 4 heures |
La cible elle-même provient d'une prévision, abordée dans la section scalabilité. Exécutez-la ensuite en cinq phases, dont les détails ci-dessous s'appuient sur l'API d'Edgegap comme exemple concret.
Préparer les clients de test. Une version simplifiée de votre backend de matchmaking qui forme les matchs, demande des serveurs, gère les notifications et enregistre chaque événement.
Augmenter progressivement la création de serveurs. Suivez la courbe ci-dessus et surveillez les erreurs de limite de débit (rate limit).
Suivre l'état de préparation. Mesurez le temps écoulé entre la demande et l'état "prêt", et examinez chaque serveur qui n'y parvient jamais.
Connecter les joueurs. Des bots si vous en avez, ou une simple vérification de connectivité brute si ce n'est pas le cas.
Nettoyer et valider. Terminez les matchs, puis recherchez les serveurs qui ont été laissés de côté.
Limites de débit. La documentation de l'API d'Edgegap indique 40 requêtes par seconde pour les déploiements et 20 pour les points de terminaison d'état et de contexte, par organisation, au 13 octobre 2026. Au-delà, les requêtes reçoivent une réponse HTTP 429. Appliquez un retard exponentiel (back off) et respectez l'en-tête Retry-After si celui-ci est renvoyé, comme le conseille le guide, et répartissez les requêtes dans le temps plutôt que d'envoyer des rafales.
Notifications. Des webhooks sont déclenchés lorsqu'un serveur est prêt, ne parvient pas à démarrer ou est arrêté. Ils ne font l'objet d'aucune tentative de renvoi. Votre gestionnaire doit donc tolérer un message manqué et un message dupliqué, et votre backend doit conserver son propre enregistrement de l'état de chaque serveur. Conservez le point de terminaison d'état comme solution de secours, car l'interrogation de centaines de serveurs épuise rapidement la limite de débit.
Nettoyage. Un serveur s'arrête lorsque votre backend le supprime, lorsque le serveur de jeu s'arrête de lui-même ou lorsqu'une durée maximale est écoulée. Marquez chaque serveur de test afin de pouvoir le retrouver plus tard, et considérez tout serveur résiduel comme un bug dans votre processus de nettoyage, car cela gonfle les coûts et fausse la session suivante.
Un mot de notre sponsor (nous-mêmes !)
La plupart des studios atteignent leur limite de mise à l'échelle lors du lancement, face aux joueurs. Edgegap a atteint 14 millions de sessions simultanées lors d'un test de référence d'une heure sur de réels conteneurs de serveurs de jeu. Ainsi, la limite que vous devez anticiper est celle de votre jeu, pas celle de votre hébergeur.
L'avis d'Edgegap (ce n'est que notre opinion, à prendre avec des pincettes !)
Exécutez le test de charge avant le lancement, couvrez toute la chaîne et prévenez votre prestataire d'abord
Un test de charge est une répétition générale, il n'est donc payant que s'il est exécuté assez tôt pour changer quelque chose. Un essai à blanc quelques semaines avant le lancement laisse le temps de corriger ce qu'il découvre. Un essai la veille au soir ne laisse que le temps de s'inquiéter.
Couvrez l'ensemble de la chaîne, car le plafond est généralement le maillon le plus faible en dehors de la build du jeu, comme le gestionnaire de notifications, la base de données ou les paramètres du matchmaker.
Et prévenez d'abord votre fournisseur. Pour un test de grande envergure, Edgegap demande à être prévenu, car il peut pré-dimensionner la capacité et augmenter les limites de débit pour la fenêtre de test. Sans cela, vous risquez de mesurer le démarrage à froid d'un fournisseur plutôt que votre propre système. Les seuils de notre guide sont supérieurs à 20 déploiements par seconde en continu, ou environ deux heures en période de pointe (article 246). Le dimensionnement de la cible est traité dans la section scalabilité.
Cela a un coût : un test réaliste demande du temps d'ingénierie, une configuration de staging et un certain délai de préavis. Un petit jeu avec quelques centaines de joueurs n'aura peut-être pas besoin de tout cela. Pour un lancement où les temps d'arrêt coûtent cher, nous pensons que s'en passer coûte plus cher. Dans le benchmark 2023 d'Edgegap, 40 déploiements par seconde maintenus pendant 60 minutes ont atteint 14 millions d'utilisateurs simultanés (CCU) sur plus de 550 sites à l'époque (benchmark).
,
