Avis de non-responsabilité : Veuillez vous assurer de nous contacter avant d'exécuter un test de charge.

Ce guide explique comment, y compris avec quels outils, exécuter un test de charge pour un jeu multijoueur en ligne, plus précisément le Matchmaking et les déploiements de serveurs de jeu sur la plateforme Edgegap à l'aide de l'API Edgegap.

Ce guide s'applique à tout moteur de jeu (par exemple, Unreal Engine, Unity, etc.), à tout genre de jeu et à tout matériel prévu (PC, Consoles, VR, WebGL, mobile, etc.).

Sujets traités (par section) :

1. Prérequis

2. Flux de Matchmaking et planification du déploiement

3. Limites de débit de l'API

4. API de déploiement

5. Gestion du cycle de vie des déploiements

6. Statut du déploiement

7. Webhooks

8. Plan d'exécution du test de charge

9. Modélisation réaliste du trafic

10. Profils de trafic

11. Cibles de trafic

12. Quand impliquer l'équipe d'Edgegap

13. Outils recommandés

Remarque : Si vous n'utilisez pas le matchmaking d'Edgegap, vous pouvez passer directement à la section #4 « API de déploiement ».

Public cible

Ce document s'adresse aux ingénieurs backend, aux équipes DevOps et aux studios qui se préparent au lancement en production.

Calendrier cible

Bien qu'il n'y ait jamais de moment idéal pour exécuter un test de charge, nous recommandons de faire un essai à blanc quelques semaines avant le lancement afin d'évaluer les faiblesses éventuelles de l'architecture de votre jeu multijoueur.

Consultez notre Check-list de pré-lancement de jeu multijoueur pour connaître le calendrier recommandé avant le lancement.

Qu'est-ce qu'un test de charge pour les jeux multijoueurs et pourquoi est-ce important

Un test de charge est un test de performance qui simule un grand nombre de joueurs simultanés (« CCU ») pour évaluer la résistance de l'infrastructure d'un jeu multijoueur sous stress, y compris le matchmaking et les déploiements de serveurs de jeu.

En effectuant des tests de charge avant le lancement, il est possible d'identifier les problèmes, tels que les fuites de mémoire, les goulots d'étranglement des requêtes de base de données, un code réseau inefficace, et de les corriger avant la sortie du jeu.

Comme nous l'avons souvent évoqué par le passé, le fait de ne pas pouvoir se préparer, et donc de ne pas pouvoir monter en charge de manière fluide lors du lancement, peut coûter des millions de dollars aux développeurs de jeux en raison de l'indisponibilité du jeu (même si vous avez dépensé des ressources de niveau AAA avant le lancement pour l'éviter).

C'est pourquoi les studios utilisent l'orchestration de serveurs de jeu d'Edgegap, qui a prouvé sa capacité à monter en charge jusqu'à 14 millions de joueurs simultanés en 60 minutes avec 40 déploiements par seconde, de manière soutenue, sur cette période. Et donc, encore plus au cours de cette première heure.  

1. Prérequis

• Objectif de cette étape : assurez-vous de disposer des prérequis nécessaires pour le test de charge.  

• But : veiller à ce que votre environnement de test reflète votre configuration de production.

Edgegap fournit une API HTTP pour gérer les déploiements de serveurs de jeu. Pour rappel, un déploiement est une instance conteneurisée de votre jeu s'exécutant sur le réseau Edge d'Edgegap.

Avant de procéder au test de charge, assurez-vous de disposer de :

• Un compte Edgegap, avec facturation configurée

• Un jeton d'API

  • Remarque : Votre jeton d'API sera inclus dans chaque en-tête de requête de cette manière : Authorization: token <votre-jeton>. Gardez ce jeton en sécurité car il donne un accès complet à vos ressources Edgegap.

• Un serveur de jeu conteneurisé packagé sous forme de version d'application Edgegap

• Un système backend capable d'effectuer des appels d'API HTTP

Sachez que la référence de l'API est disponible dans notre documentation ici : https://docs.edgegap.com/docs/api

2. Comprendre le Matchmaking et la planification du déploiement

• Objectif de cette étape : Déterminer comment votre système de matchmaking traduit l'activité des joueurs en requêtes de déploiement.

• But : Simuler avec précision le comportement réel des joueurs au sein du flux de déploiement du jeu. Parallèlement, estimer un nombre suffisant de déploiements pour correspondre aux données de performance qui reflètent le jour du lancement.

Dans un environnement multijoueur de production, votre flux de matchmaking ressemble généralement à ceci :

Connexion du joueur → File d'attente de Matchmaking → Match trouvé → Déploiement créé → Serveur prêt → Connexion des joueurs → Match en cours → Déploiement supprimé

L'élément clé ici est que chaque match nécessite exactement un déploiement. Cette relation un pour un est la base de votre planification de capacité.

Calcul de vos besoins de déploiement

Faisons le calcul. Si votre jeu prend en charge N joueurs par instance de serveur, vous pouvez calculer exactement le nombre de déploiements dont vous pourriez avoir besoin :

Cela signifie concrètement que les « Déploiements requis » correspondent au nombre cible de déploiements visé.

Estimation de l'évolution de la base de joueurs

En utilisant le nombre de déploiements par nombre total de joueurs, l'étape suivante consiste à estimer le nombre de ces déploiements au fil du temps (c'est-à-dire la « montée en charge »).

C'est là que la plupart des développeurs de jeux font l'erreur de tester la charge de l'ensemble de leur base de joueurs en quelques minutes, en surestimant le nombre de déploiements par seconde pour « monter en charge » vers leurs objectifs de lancement.

À titre d'exemple, le jeu le plus populaire au monde, Fortnite, a atteint un pic historique d'utilisateurs simultanés à 14,3 millions avec une estimation de 100 déploiements par seconde. Pourtant, Fortnite enregistre une moyenne de 30 à 40 déploiements par seconde lors de ses pics quotidiens. En effet, les joueurs rejoignent et quittent les parties en fonction de leur vie quotidienne (sommeil, travail) comme des vagues. Ainsi, de manière réaliste, même si un jeu est lancé dans le monde entier en même temps, un test de charge doit tabler sur 25 à 50 % de ses utilisateurs simultanés au pic de lancement répartis sur 60 minutes pour être réaliste.

c'est-à-dire que la formule est : (déploiements requis * % du pic estimé) / 3 600 secondes = objectif de déploiements par seconde pour le test de charge

3. Respecter les limites de débit de l'API (Crucial)

• Objectif de cette étape : Comprendre et respecter les limites de débit de déploiement des serveurs.

• But : S'assurer que votre test de charge reflète les contraintes du monde réel. Évitez d'atteindre les limites de débit pendant votre test, car cela pourrait masquer de réels problèmes de performance. Bien que cela soit peu probable, si vous rencontrez les mêmes limites en production, votre test doit en tenir compte.

Edgegap applique des limites de débit à l'échelle de l'organisation pour garantir la stabilité du système. Celles-ci s'appliquent à l'ensemble de l'organisation.

Veuillez vous référer à la documentation, mais les limites de débit de l'API d'Edgegap sont à l'heure où nous écrivons ces lignes :

Plus précisément pour le matchmaking, chaque niveau comporte les limites suivantes :

Lorsque vous dépassez ces limites, l'API renvoie l'erreur HTTP 429 – Too Many Requests. Veillez à respecter ces limites pour éviter ce message d'erreur.

Bonnes pratiques pour le respect des limites de débit

Pour rester dans les limites et garantir des performances fiables :

• Implémentez un backoff exponentiel lorsque vous recevez une réponse 429. Ne vous contentez pas de réessayer immédiatement, car cela aggrave le problème.

• Respectez toujours l'en-tête Retry-After dans les réponses 429. Il vous indique exactement combien de temps attendre avant de réessayer.

• Évitez les pics soudains en répartissant les requêtes de déploiement dans le temps. Des montées en charge progressives sont de toute façon plus réalistes.

• Utilisez des webhooks plutôt que des requêtes régulières (polling) pour suivre l'état des déploiements. Cela réduit considérablement l'utilisation de votre point de terminaison de statut.

⚠️ Important : Si vous planifiez un test de charge à grande échelle (charge soutenue sur plusieurs heures ou taux de déploiement élevés), coordonnez-vous au préalable avec le support d'Edgegap. Ils peuvent augmenter temporairement vos limites et pré-dimensionner la capacité pour garantir des résultats de test précis.

4. Créer des déploiements via l'API

• Objectif de cette étape : Apprendre à créer par programmation des déploiements de serveurs de jeu avec une configuration et une surveillance appropriées.

• But : La réalisation des appels d'API est au cœur du flux de déploiement. Elle garantit que vos serveurs se déploient à l'emplacement optimal pour tous les joueurs et avec les notifications de webhooks appropriées.

Le point de terminaison de création de déploiement est votre interface principale pour lancer des serveurs de jeu.

Le point de terminaison Create Deployment

Point de terminaison : POST https://api.edgegap.com/v2/deployments

Limite de débit : 40 requêtes/seconde (à l'échelle de l'organisation)

En-têtes requis :

Authorization: token <votre-jeton>
Content-Type: application/json

Exemple de corps de requête

Voici un exemple complet montrant tous les paramètres clés que vous devez inclure :

{
  "application": "my-game-server",
  "version": "v1.0.0",
  "users": [
    {
      "user_type": "ip_address",
      "user_data": {
        "ip_address": "1.2.3.4"
      }
    }
  ],
  "tags": ["matchmaking", "load-test"],
  "webhook_on_ready": {
    "url": "https://your-backend.com/webhooks/deployment-ready",
    "method": "POST"
  },
  "webhook_on_error": {
    "url": "https://your-backend.com/webhooks/deployment-error",
    "method": "POST"
  }
}

Comprendre les paramètres clés

• Tableau users : C'est ainsi qu'Edgegap détermine l'emplacement géographique optimal pour votre déploiement. Incluez les adresses IP des joueurs qui se connecteront à ce match. Le système utilise ces informations pour sélectionner l'emplacement Edge qui minimise la latence pour tous les participants.

• Webhooks : Fortement recommandés par rapport au polling. Les webhooks vous envoient des notifications instantanées lorsque les déploiements sont prêts ou rencontrent des erreurs, ce qui vous permet d'intégrer immédiatement les joueurs dans les matchs sans vérification constante du statut.

• Tags : Utilisez des tags pour organiser et filtrer vos déploiements. Pendant le test de charge, les tags vous aident à identifier les déploiements qui appartiennent à votre test par rapport au trafic de production.

5. Gérer le cycle de vie du déploiement

• Objectif de cette étape : Mettre en œuvre un nettoyage approprié des déploiements afin d'éviter le gaspillage de ressources et de garantir des mesures précises du test de charge.

• But : Les déploiements orphelins qui ne sont pas correctement arrêtés gonfleront vos coûts, consommeront de la capacité et rendront les résultats de votre test de charge insignifiants, car vous devez observer comment le système gère le cycle complet création-exécution-suppression.

Une erreur courante lors des tests de charge consiste à se concentrer uniquement sur la création du déploiement tout en ignorant le nettoyage. Dans un environnement de production réel, les matchs se terminent, ce qui arrête les serveurs afin d'éviter des dépenses excessives en ressources. Votre test de charge doit simuler ce cycle de vie complet (et vous faire économiser de l'argent sur le test de charge lui-même).

Supprimer des déploiements depuis votre backend

Lorsqu'un match se termine, votre backend de matchmaking doit immédiatement supprimer le déploiement.

Point de terminaison

DELETE https://api.edgegap.com/v2/deployments/{request_id}

En-têtes

Authorization: token <votre-jeton>

Le request_id est renvoyé lorsque vous créez le déploiement. Enregistrez cet identifiant dans votre système de matchmaking afin de pouvoir vous y référer à la fin du match.

Alternative : Auto-résiliation (c'est-à-dire laisser le serveur de jeu décider)

Il existe une autre approche qui vous offre plus de flexibilité : chaque déploiement comprend une URL de suppression et un jeton uniques qui permettent au serveur de jeu lui-même de s'éteindre le moment venu. Cela est particulièrement utile lorsque la logique de votre jeu sait mieux que quiconque quand un match est véritablement terminé.

Par exemple, votre serveur de jeu peut attendre que tous les joueurs se soient déconnectés, que les statistiques d'après-match soient téléchargées et que les replays soient enregistrés avant de déclencher sa propre fermeture. Cette approche garantit que rien n'est perdu lors du processus de nettoyage.

Pour en savoir plus sur l'auto-résiliation, consultez la documentation d'Edgegap sur le cycle de vie des déploiements.

Rappel : Coûts liés au non-arrêt des serveurs

Le fait de ne pas supprimer correctement les déploiements aura pour conséquences de :

• Augmenter considérablement vos coûts, car vous payez pour des serveurs inactifs

• Fausser les résultats de votre test de charge en donnant l'impression que vous avez besoin de plus de capacité qu'en réalité

• Créer des problèmes opérationnels car votre tableau de bord se remplit de déploiements fantômes

Pendant votre test de charge, mettez en place un suivi à l'aide des analyses d'Edgegap afin de détecter tout déploiement qui n'est pas correctement nettoyé.

-> Ces déploiements orphelins sont un signal d'alarme indiquant que la gestion de votre cycle de vie doit être ajustée avant le lancement.

6. Suivre le statut du déploiement

• Objectif de cette étape : Comprendre comment surveiller la disponibilité des déploiements sans surcharger l'API avec des vérifications d'état.

• But : Savoir exactement quand un déploiement est prêt à accueillir des joueurs est crucial pour le flux de matchmaking. Cependant, un polling agressif peut déclencher des limites de débit et ne reflète pas les bonnes pratiques de production.

Après avoir créé un déploiement, vous devez savoir quand il est prêt pour que les joueurs s'y connectent. Il existe deux approches : interroger le point de terminaison de statut ou utiliser des webhooks. L'une est nettement meilleure que l'autre.

Les Webhooks : La bonne approche

Au lieu de demander « est-ce que c'est prêt ? » toutes les secondes, laissez Edgegap vous avertir immédiatement dès qu'un changement survient. C'est le rôle des webhooks, et c'est l'approche recommandée pour les systèmes de production (voir l'étape 7).

Lorsque vous incluez des URL de webhooks dans votre requête de création de déploiement (comme indiqué dans la section 4), Edgegap envoie un POST HTTP à votre backend dès qu'un déploiement devient disponible ou rencontre une erreur. Votre système peut alors immédiatement attribuer les joueurs à ce serveur de match sans aucun délai d'attente lié au polling.

Bonne pratique : Utilisez les webhooks comme principal mécanisme de notification. Réservez le point de terminaison de statut aux cas exceptionnels où vous devez vérifier manuellement l'état d'un déploiement — par exemple lors d'un débogage ou pour gérer de rares cas limites.

Le point de terminaison de statut (à utiliser avec parcimonie)

GET https://api.edgegap.com/v1/status/{request_id}

Limite de débit : 10 requêtes/seconde

Ce point de terminaison renvoie l'état actuel d'un déploiement :

• Status.DEPLOYING – Le serveur est en cours de démarrage

• Status.READY – Le serveur est prêt pour les connexions des joueurs

• Status.ERROR – Une erreur est survenue lors du déploiement

Bien que ce point de terminaison fonctionne, l'interroger à plusieurs reprises pour des centaines de déploiements devient rapidement problématique. Vous épuiserez rapidement votre limite de débit et créerez une charge inutile sur l'API.

7. Implémenter des webhooks pour une surveillance de niveau production

• Objectif de cette étape : Configurer une gestion fiable des webhooks pour recevoir des notifications de déploiement en temps réel.

• But : Les webhooks éliminent la surcharge liée au polling et fournissent des notifications instantanées, ce qui est essentiel pour concevoir un système de matchmaking réactif capable d'intégrer les joueurs dans les parties sans délai.

Les webhooks sont des rappels HTTP qu'Edgegap envoie à votre backend lorsque l'état d'un déploiement change. Considérez-les comme des notifications push pour votre système de matchmaking. Au lieu de vérifier constamment si un événement s'est produit, vous en êtes immédiatement informé.

Événements de webhooks disponibles

La charge utile du webhook contient les mêmes données que le point de terminaison /v1/status/{request_id} ; vous obtenez des informations complètes sur le déploiement, y compris les détails de connexion, la région et le statut.

Exigences des webhooks

• Renvoyer HTTP 2xx : Votre point de terminaison de webhook doit renvoyer un code d'état de réussite (200-299) pour accuser réception. Tout autre code d'état ou délai d'attente dépassé signale un échec.

• Pas de tentatives automatiques : Edgegap ne réessaie pas d'envoyer les webhooks qui ont échoué. Si votre point de terminaison est indisponible ou renvoie une erreur, vous manquez cette notification. C'est pourquoi vous devez implémenter votre propre logique de tentative et maintenir l'état des déploiements dans votre backend.

• Implémenter l'idempotence : Bien qu'Edgegap ne fasse pas de nouvelles tentatives, des problèmes réseau ou vos propres systèmes peuvent vous amener à traiter le même webhook plusieurs fois. Concevez votre gestionnaire de webhooks de manière à traiter en toute sécurité les notifications en double sans corrompre votre état.

Bonnes pratiques

• Utiliser les webhooks pour piloter l'affectation des joueurs : cela réduit le temps d'attente des joueurs et élimine la surcharge liée au polling constant d'état. Pendant votre test de charge, mesurez la rapidité avec laquelle vous pouvez passer de la création du déploiement à la connexion du joueur. Voici un flux type :

  • Le match est créé, le déploiement est lancé avec le webhook_on_ready configuré

  • Les joueurs attendent dans un état « démarrage du match »

  • Le webhook arrive sur votre backend : « le déploiement XYZ est prêt »

  • Votre backend envoie immédiatement les détails de connexion aux joueurs en attente

  • Les joueurs se connectent et le match commence

• Enregistrer l'état du déploiement : Ne vous fiez pas uniquement aux webhooks. Maintenez une base de données des états de déploiement dans votre backend afin de pouvoir récupérer des notifications manquées ou faire face à des redémarrages de système. Utilisez les webhooks pour mettre à jour cet état, mais conservez la source de vérité dans votre propre infrastructure.

• Éviter le polling agressif

8. Suggestion de plan d'exécution du test de charge

• Objectif de cette étape : Créer un test de charge structuré et multiphase qui valide chaque aspect de votre pipeline de déploiement.

• But : Tenter de simuler un calendrier de votre lancement et du parcours des joueurs pour s'assurer que chaque composant fonctionne sous pression de manière similaire au jour du lancement.

Phase 1 : Préparer les clients de test

Avant de pouvoir créer des déploiements, vous avez besoin de quoi les générer. Créez des clients de test qui simulent le comportement de votre système de matchmaking :

• Simuler un trafic de matchmaking réaliste qui reflète la manière dont les joueurs se mettent réellement en file d'attente pour jouer

• Générer des requêtes de déploiement depuis votre backend lorsque des matchs se forment

• Gérer les réponses des webhooks et mettre à jour l'état du match en conséquence

• Suivre tous les événements du cycle de vie des déploiements pour une analyse ultérieure

Ces clients de test sont essentiellement une version simplifiée de votre backend de matchmaking de production. Ils n'ont pas besoin d'être aussi robustes, mais ils doivent représenter fidèlement vos modèles d'utilisation de l'API.

Phase 2 : Exécuter la rampe de création de déploiements

Commencez à créer des déploiements progressivement, en respectant les limites de débit et en suivant une courbe d'arrivée réaliste. Cette phase teste votre capacité à augmenter la création de déploiements à mesure que le trafic de joueurs augmente :

• Commencer lentement et monter en puissance progressivement — évitez les pics soudains qui ne reflètent pas le comportement réel des joueurs

• Rester largement dans les limites de débit de l'API en répartissant les requêtes de manière uniforme

• Suivre une courbe progressive qui simule l'arrivée organique des joueurs (plus d'informations à ce sujet dans la section 10)

• Surveiller les erreurs de limite de débit et ajuster la cadence si vous rencontrez des réponses 429

Cette phase valide que votre logique de création de déploiements peut gérer le taux d'arrivée des joueurs attendu sans surcharger l'API.

Phase 3 : Suivre la disponibilité des déploiements

Au fur et à mesure du démarrage des déploiements, surveillez le moment où ils deviennent prêts pour les connexions des joueurs :

• S'appuyer principalement sur les webhooks pour les notifications de disponibilité (comme indiqué dans la section 7)

• Optionnellement, interroger /v1/status avec parcimonie si les webhooks ne sont pas réalisables pour votre configuration de test

• Mesurer le temps d'activation pour chaque déploiement — cela a un impact direct sur le temps d'attente des joueurs

• Suivre les taux d'erreur et examiner les déploiements qui ne parviennent pas à atteindre l'état READY

Si vous constatez des temps de déploiement longs ou des taux d'erreur élevés au cours de cette phase, vous devez faire des recherches avant d'aller plus loin. Ces problèmes s'amplifieront lorsque vous passerez à la charge de production complète.

Phase 4 : Simuler les connexions des joueurs (si possible)

Cette phase est facultative mais très précieuse. Une fois que les déploiements affichent READY, connectez réellement des joueurs simulés pour tester l'intégralité du pipeline :

• Lancer des bots clients de jeu qui se connectent à l'aide des informations de connexion du déploiement

• Suivre les taux de réussite des connexions — certains déploiements peuvent indiquer READY tout en échouant lors des connexions

• Mesurer la latence du réseau depuis les emplacements des joueurs simulés jusqu'aux serveurs qui leur sont attribués

• Vérifier les fonctionnalités de gameplay si vos bots peuvent exécuter des actions de base dans le jeu

Cette phase révèle des problèmes qui n'apparaissent que lorsque de réelles connexions clients ont lieu. Si vous ne pouvez pas simuler un client de jeu complet, testez au moins la connectivité réseau brute vers l'IP et le port de chaque déploiement.

Phase 5 : Exécuter le nettoyage et la validation

La phase finale valide la gestion du cycle de vie de vos déploiements :

• Arrêter les déploiements au fur et à mesure que les matchs simulés se terminent (voir la section 5)

• Rechercher les déploiements orphelins qui n'ont pas été nettoyés correctement

• Vérifier l'exactitude du cycle de vie en s'assurant que les déploiements passent par tous les états attendus

• Analyser les données recueillies au cours de toutes les phases pour identifier les goulots d'étranglement et les défaillances

Une phase de nettoyage réussie doit afficher zéro déploiement orphelin et confirmer que votre système gère correctement le cycle complet création-exécution-suppression à grande échelle.

9. Modéliser un trafic de joueurs réaliste

• Objectif de cette étape : Concevoir des modèles de test de charge qui reflètent fidèlement la manière dont les vrais joueurs rejoignent les matchs d'un jeu et adaptent vos déploiements de serveurs de jeu.

• But : S'aligner sur des modèles de trafic réalistes pour générer des informations significatives. Si votre test ne correspond pas à un comportement réaliste, vous ne découvrirez pas les problèmes potentiels lors du lancement.

Voici une vérité essentielle concernant les tests de charge : les tests de stress synthétiques ne révèlent pas les problèmes de production.

Si vous créez 1 000 déploiements instantanément, vous ne simulez pas un lancement réel, vous prouvez simplement que l'API peut rejeter vos requêtes avec des erreurs 429.

Ce qu'il faut éviter

Évitez ces modèles de test irréalistes :

• Créer des milliers de déploiements instantanément : les vrais joueurs n'arrivent pas tous à la milliseconde près

• Ignorer le flux de matchmaking : les déploiements de production sont créés au fur et à mesure que les matchs se forment, pas via un minuteur

• Sauter le nettoyage des déploiements : les vrais matchs se terminent et libèrent de la capacité pour de nouveaux matchs

• Tester uniquement de courtes sessions : la charge de production est soutenue sur plusieurs heures, révélant des problèmes que les tests courts ne détectent pas

• Exécuter des tests sans orchestration backend : votre système réel intègre une logique de matchmaking, des files d'attente et une gestion des états

Ces modèles peuvent stresser le système, mais ils ne valident pas le bon fonctionnement de votre architecture de production réelle.

Ce qu'un bon test de charge simule

Un test de charge réaliste modélise ces comportements. Par exemple, alignez-vous sur des comparaisons de jeux à l'aide du tracker de CCU de SteamDB. Par exemple, le succès massif de PEAK a mis plusieurs jours à atteindre son pic maximal de CCU, avec sa plus forte augmentation de 40 000 CCU réalisée sur une journée entière, pour une moyenne de 20 000 CCU par rapport à son pic sur cette même journée.

• Taux d'arrivée des joueurs : les joueurs arrivent d'abord au compte-gouttes, puis par vagues pendant les heures de pointe.

• Fréquence de création des matchs : basée sur la rapidité avec laquelle votre outil de matchmaking peut former des groupes

• Cycle de vie complet du déploiement : création, disponibilité, connexions des joueurs, durée du match et nettoyage

• Durée de session variable : certains matchs sont rapides, d'autres durent plus longtemps

• Distribution géographique : les joueurs proviennent de différentes régions, ce qui influe sur le positionnement du déploiement

Lorsque vous modélisez ces facteurs, votre test de charge devient une véritable validation de votre état de préparation pour la production, et pas seulement un test de stress d'API.

10. Exemples de profils de trafic

Comme indiqué précédemment, le scénario le plus probable consistera à faire correspondre un titre comparable dans le même genre et avec la même portée de projet à l'aide de SteamDB, puis à appliquer un multiplicateur pour une sortie simultanée sur console (3-5x pour PlayStation, 1x pour XBOX).

Ceci étant dit, examinons trois scénarios d'échelle différents. Évaluez celui qui correspond au trafic de lancement prévu, ou créez un profil personnalisé basé sur ces exemples

Scénario A : Lancement d'un jeu indépendant (200 joueurs simultanés)

Plan de test recommandé : Passer de 0 à 5 déploiements/minute sur 10 minutes, puis maintenir pendant 60 minutes.

Scénario B : Titre multijoueur de taille moyenne (2 000 joueurs simultanés)

Plan de test recommandé : Passer de 0 to 20 déploiements/minute sur 20 minutes, puis maintenir pendant 90 minutes.

Scénario C : Grand événement / Weekend Bêta (10 000 joueurs simultanés)

Plan de test recommandé : Passer de 0 to 50 déploiements/minute sur 30 minutes, puis maintenir pendant 2 à 4 heures.

Mettre en œuvre une courbe de montée en charge réaliste

Quelle que soit votre échelle, suivez un modèle de montée en charge progressive de ce type :

Temps (minutes) → Déploiements/minute
0–10     → 0 → 5
10–20     → 5 → 15
20–30     → 15 → 30
30–60     → Maintien au pic

Cette courbe progressive simule :

• L'arrivée organique des joueurs à mesure que la nouvelle se répand que les serveurs sont en ligne

• La mise en route du matchmaker à mesure que les files d'attente se remplissent et que les matchs commencent à se former

• La courbe d'approvisionnement des déploiements à mesure qu'Edgegap ajuste sa capacité pour répondre à la demande

• La stabilisation du routage réseau à mesure que les modèles de trafic s'établissent et s'optimisent

Ajoutez également un peu d'aléa dans le timing de vos déploiements. Ne les créez pas à la seconde près. Le matchmaking réel présente des variations naturelles dans la formation des matchs.

11. Définir des objectifs de validation de la production

• Objectif de cette étape : Établir des critères de réussite clairs pour savoir si votre test de charge a réussi ou a révélé des problèmes.

• But : Des indicateurs concrets sont nécessaires pour déterminer si vous êtes prêt pour le lancement ou si vous devez procéder à de nouvelles optimisations.

Un test de charge réussi ne se résume pas à « fonctionner sans planter ». Vous devez définir des objectifs de performance spécifiques garantissant une expérience de jeu acceptable. Voici les indicateurs clés à valider :

• Latence de création de match : Mesure le temps nécessaire entre « match formé » et « appel d'API de déploiement terminé ». Les joueurs attendent pendant ce temps, donc le maintenir sous la barre des 5 secondes garantit une bonne expérience utilisateur.

• Temps de disponibilité du déploiement : Dépend fortement de la rapidité avec laquelle votre serveur de jeu conteneurisé peut démarrer et devenir prêt pour les connexions. Optimisez le temps de démarrage de votre conteneur pendant le développement — un démarrage de 30 secondes est préférable à un démarrage de 2 minutes.

• Succès de la connexion des joueurs : Un taux supérieur à 99 % signifie que presque tous les joueurs se connectent avec succès au serveur qui leur est attribué. Si vous constatez des échecs de connexion, cherchez à savoir s'il s'agit d'un problème réseau, d'un dysfonctionnement du serveur de jeu ou de détails de connexion incorrects fournis aux clients.

• Saturation de la limite de débit de l'API : Vous devez terminer votre test de charge sans atteindre les limites de débit. Si vous obtenez des erreurs 429, votre modèle de requête de déploiement est trop agressif et ne fonctionnera pas non plus en production.

• Déploiements orphelins : Zéro orphelin signifie que la gestion de votre cycle de vie fonctionne correctement. Même un seul déploiement orphelin suggère un bug dans votre logique de nettoyage qui gaspillera des ressources à grande échelle.

Utilisez les données du test de charge pour identifier les goulots d'étranglement, optimiser vos systèmes et tester à nouveau. Il est bien préférable de retarder le lancement que de faire face à des défaillances d'infrastructure avec de vrais joueurs.

12. Se coordonner avec Edgegap pour les tests à grande échelle

• Objectif de cette étape : S'assurer que l'infrastructure d'Edgegap est prête à soutenir votre test de charge à grande échelle.

• But : Les tests de charge de grande envergure nécessitent une coordination pour garantir des résultats précis.

Si votre test de charge implique une échelle significative, ne vous contentez pas de solliciter l'API de manière intensive. Prévenez Edgegap pour nous aider à préparer notre infrastructure à gérer correctement votre test, comme nous le ferions pour un lancement d'envergure.

Quand faut-il se coordonner à l'avance

Informez Edgegap si votre test implique :

• Plus de 20 déploiements par seconde de manière soutenue dans le temps

• Une charge soutenue sur plusieurs heures (plus de 2 heures au pic)

• Un trafic simultané multi-régions couvrant plusieurs zones géographiques

• Des tests planifiés à l'approche de votre date de lancement pour lesquels vous avez besoin de résultats garantis

Contactez Edgegap via la section Tableau de bord → Outils ou via la communauté Discord d'Edgegap. Fournissez des détails sur le taux de déploiement attendu, la durée du test et les régions ciblées.

Ce que permet la coordination

Lorsque vous vous coordonnez à l'avance, Edgegap peut :

• Pré-dimensionner la capacité dans les régions où vous effectuerez les tests, garantissant que des serveurs soient immédiatement disponibles

• Augmenter temporairement les limites de débit si votre test nécessite légitimement un débit plus élevé

• Surveiller la disponibilité de l'infrastructure et traiter de manière proactive les contraintes de capacité

• Fournir une assistance technique si vous rencontrez des problèmes inattendus pendant le test

Cette coordination permet de s'assurer que votre test reflète fidèlement les performances de production, plutôt que de mesurer les capacités de montée en charge à froid d'Edgegap. L'objectif est avant tout de valider votre propre système.

13. Outils de test de charge recommandés

Pour exécuter vos tests de charge, nous vous recommandons deux outils standards de l'industrie : Apache JMeter et k6.

Tous deux sont spécialement conçus pour tester la charge des API et peuvent simuler des modèles de requêtes de déploiement réalistes tout en respectant les limites de débit.

• Apache JMeter : JMeter fournit une interface visuelle pour concevoir des scénarios de test complexes, ce qui le rend idéal pour les équipes qui préfèrent une configuration de test basée sur une interface graphique et souhaitent disposer de tableaux de bord de rapport intégrés sans avoir à écrire de code.

• k6 : k6 utilise JavaScript pour les scripts de test et excelle dans l'intégration CI/CD moderne, ce qui convient parfaitement aux équipes qui souhaitent gérer les versions de leurs tests de charge aux côtés de leur code et automatiser les tests dans les pipelines de déploiement.

Conclusion

Le test de charge de l'infrastructure de votre jeu multijoueur est une étape cruciale avant votre lancement.

C'est l'occasion de découvrir et de corriger les problèmes avant qu'ils n'affectent les vrais joueurs. En suivant cette approche complète, vous validerez non seulement que vos serveurs peuvent supporter la charge, mais aussi que l'ensemble de votre pipeline allant du matchmaking au gameplay fonctionne de manière fiable à grande échelle.

Bonne chance pour votre lancement ! Si vous avez des questions ou si vous avez besoin d'aide concernant votre stratégie de test de charge, l'équipe d'Edgegap est là pour vous aider sur Discord, par e-mail ou sur Slack (sur demande).