Ce guide explique comment, y compris les outils nécessaires, effectuer un test de charge pour un jeu multijoueur en ligne, spécifiquement le matchmaking et les déploiements de serveurs de jeu sur la plateforme Edgegap en utilisant l'API Edgegap.

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

Sujets couverts (par section) :

1. Pré-requis

2. Flux de Matchmaking et planification de déploiement

3. Limites de taux de l'API

4. APIs de déploiement

5. Gestion du cycle de vie des déploiements

6. Statut des déploiements

7. Webhooks

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

9. Modélisation de trafic réaliste

10. Profils de trafic

11. Objectifs 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 à la section #4 « API de déploiement ».

Public Cible

Ce document est destiné aux ingénieurs backend, aux équipes DevOps et aux studios préparant le lancement en production.

Calendrier Cible

Bien qu'il n'y ait jamais de moment idéal pour réaliser un test de charge, nous recommandons de faire une répétition générale quelques semaines avant le lancement pour évaluer toute faiblesse dans l'architecture de votre jeu multijoueur.

Consultez notre liste de contrôle pré-lancement pour les jeux multijoueurs pour un calendrier recommandé avant le lancement.

Qu'est-ce qu'un Test de Charge pour les Jeux Multijoueurs et Pourquoi c'est Important

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

En testant la charge avant le lancement, des problèmes peuvent être identifiés, tels que les fuites de mémoire, les goulets d'étranglement dans les requêtes de base de données, le code réseau inefficace, et être corrigés avant la sortie.

Comme nous l'avons souvent couvert par le passé, l'incapacité de se préparer et donc de s'adapter sans accroc au 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 des serveurs de jeu Edgegap, qui a prouvé sa capacité à s'adapter à 14 millions de joueurs simultanés en 60 minutes avec 40 déploiements par seconde, soutenus, sur cette période. Et donc, encore plus au cours de cette première heure.  

1. Pré-requis

• Objectif de cette étape : assurez-vous d'avoir les pré-requis nécessaires pour le test de charge.  

• But : garantir 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. En guise de rappel, un déploiement est une instance conteneurisée de votre jeu fonctionnant sur le réseau périphérique d'Edgegap.

Avant de tester la charge, assurez-vous d'avoir :

• Un compte Edgegap, avec la 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>. Conservez ce jeton en sécurité car il a un accès complet à vos ressources Edgegap.

• Un serveur de jeu conteneurisé emballé comme une 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 de Déploiement

• Objectif de cette étape : Cartographier comment votre système de matchmaking traduit l'activité des joueurs en demandes de déploiement.

• But : Simuler avec précision le comportement réel des joueurs dans le flux de déploiement du jeu. De plus, estimer suffisamment de déploiements pour correspondre aux données de performances reflétant 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 → Joueurs connectés → Match en cours → Déploiement supprimé

L'idée cruciale ici est que chaque match nécessite exactement un déploiement. Cette relation un à un est la base de votre planification de capacité.

Calcul de Vos Besoins en Déploiement

Travaillons ensemble sur les calculs. Si votre jeu prend en charge N joueurs par instance de serveur, vous pouvez calculer exactement combien de déploiements vous pourriez avoir besoin :

Cela signifie effectivement que « Déploiements requis » est le nombre cible de déploiements prévu.

Estimation de l'Échelle des Bases de Joueurs

En utilisant le nombre de déploiements par joueurs totaux, l'étape suivante consiste à estimer le nombre de ces déploiements au fil du temps (c'est-à-dire, « mise à l'échelle »).

C'est là que la plupart des développeurs de jeux commettent l'erreur de tester la charge de leur base de joueurs entière en quelques minutes, en surestimant le nombre de déploiements par secondes à « structurer » pour atteindre leurs objectifs de lancement.

Par exemple, le jeu le plus populaire au monde, Fortnite, son pic tout temps de joueurs simultanés à 14,3 millions avec une estimation de 100/déploiements par secondes. Pourtant, Fortnite a une moyenne de 30 à 40 déploiements par secondes à ses pics quotidiens. Comme les joueurs rejoignent et quittent les parties en fonction de leur vie quotidienne (sommeil, travail) comme des vagues. Ainsi, réalistement, même si un jeu est lancé dans le monde entier en même temps, un test de charge doit prendre en compte 25 à 50 % de ses utilisateurs simultanés de lancement de pointe s'adaptant sur 60 minutes pour être réaliste.

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

3. Respecter les Limites de Taux de l'API (Critique)

• Objectif de cette étape

• But :

Comprenez et travaillez dans les limites de taux de déploiement de serveurs.

Edgegap applique des limites de taux à l'échelle de l'organisation pour assurer la stabilité du système. Elles s'appliquent à l'ensemble de l'organisation.

Veuillez consulter la documentation, mais les limites de taux de l'API d'Edgegap sont à jour :

En particulier pour Matchmaking, chaque niveau a les limites suivantes :

Lorsque vous dépassez ces limites, l'API retourne HTTP 429 – Trop de Requêtes. Assurez-vous de respecter ces limites pour éviter ce message d'erreur.

Meilleures Pratiques pour la Conformité aux Limites de Taux

Pour rester dans les limites et garantir des performances fiables :

• Implémentez une recul exponentiel lorsque vous recevez une réponse 429. Ne réessayez pas immédiatement car cela ne fait qu'aggraver le problème.

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

• Évitez les pics soudains en répartissant les demandes de déploiement dans le temps. Les augmentations progressives sont de toute façon plus réalistes.

• Utilisez les webhooks au lieu de l'interrogation pour suivre le statut des déploiements. Cela réduit considérablement votre utilisation du point de terminaison de statut.

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

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

• Objectif de cette étape: Apprenez à programmer sic eventsestmettre les déploiements de serveurs de jeu avec une configuration et une surveillance correctes.

• But: Obtenir les appels d'API est essentiel à l'évolution du déploiement. Cela garantit que vos serveurs se déploient à l'emplacement optimal pour tous les joueurs et envoie les notifications de webhook appropriées.

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

Point de terminaison de Création de Déploiement

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

Limite de Taux: 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": "mon-serveur-de-jeu",

  "version": "v1.0.0",

  "users": [

    {

      "user_type": "adresse IP",

      "user_data": {

        "ip_address": "1.2.3.4"

      }

    }

  ],

  "tags": ["matchmaking", "load-test"],

  "webhook_on_ready": {

    "url": "https://votre-backend.com/webhooks/deployment-ready",

    "method": "POST"

  },

  "webhook_on_error": {

    "url": "https://votre-backend.com/webhooks/deployment-error",

    "method": "POST"

  }

}

Comprenez les Paramètres Clés

• Tableau des utilisateurs: 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 périphérique qui minimise la latence pour tous les participants.

• Webhooks: Fortement recommandés par rapport à l'interrogation. Les webhooks vous donnent des notifications instantanées lorsque les déploiements deviennent prêts ou rencontrent des erreurs, vous permettant ainsi de déplacer les joueurs dans les matchs sans vérifications constantes des statuts.

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

5. Gérer le Cycle de Vie des Déploiements

• Objectif de cette étape: Implémentez un nettoyage correct des déploiements pour éviter le gaspillage de ressources et assurez des métriques de test de charge précises.

• But: Les déploiements orphelins qui ne sont pas correctement terminés augmenteront vos coûts, consommeront de la capacité et rendront vos résultats de test de charge insignifiants car vous devez voir comment le système gère l'intégralité du cycle de création-exécution-suppression.

Une erreur courante dans le test de charge est de se concentrer uniquement sur la création de déploiement en ignorant le nettoyage. Dans un environnement de production réel, les matches se terminent ce qui met fin aux serveurs pour éviter de dépenser trop de 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 les 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. Stockez cet ID dans votre système de matchmaking afin de pouvoir s'y référer lorsque le match se termine.

Alternative : Auto-termination (c'est-à-dire, Laissez le Serveur de Jeu Décider)

Il existe une approche alternative qui vous donne plus de flexibilité : chaque déploiement inclut une URL de suppression unique et un jeton qui permet au serveur de jeu de s'arrêter lui-même au moment opportun. Cela est particulièrement utile lorsque votre logique de jeu sait le mieux quand un match est vraiment terminé.

Par exemple, votre serveur de jeu pourrait 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 rediffusions soient sauvegardées avant de déclencher sa propre terminaison. Cette approche garantit qu'aucune donnée n'est perdue dans le processus de nettoyage.

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

Rappel: Coûts de l'Échec de Terminer les Serveurs

Ne pas supprimer correctement les déploiements :

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

• Biaise vos résultats de test de charge en faisant apparaître que vous avez besoin de plus de capacité que vous en avez réellement besoin

• Crée des problèmes opérationnels alors que votre tableau de bord se remplit de déploiements zombies

Durant votre test de charge, implémentez une surveillance à l'aide des analyses de Edgegap pour détecter les déploiements qui ne sont pas correctement nettoyés.

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

6. Suivi du Statut des Déploiements

• Objectif de cette étape: Comprendre comment surveiller l'état de préparation des déploiements sans submerger l'API de vérifications de statut.

• But: Savoir exactement quand un déploiement est prêt à accepter les connexions des joueurs est crucial pour le flux de matchmaking. Cependant, une interrogation agressive peut déclencher des limites de taux et ne reflète pas les meilleures pratiques de production.

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

Webhooks : La Bonne Approche

Au lieu de demander "est-ce prêt ?" chaque seconde, laissez Edgegap vous avertir immédiatement lorsque quelque chose change. C'est ce que font les webhooks, et ils sont l'approche recommandée pour les systèmes de production (voir l'étape 7).

Lorsque vous incluez des URL de webhook dans votre demande de création de déploiement (comme montré dans la section 4), Edgegap enverra un POST HTTP à votre backend dès qu'un déploiement devient prêt ou rencontre une erreur. Votre système peut alors immédiatement assigner des joueurs à ce serveur de match sans aucun délai d'interrogation.

Meilleure pratique : Utilisez les webhooks comme votre mécanisme principal de notification. Réservez le point de terminaison de statut pour des cas exceptionnels où vous avez besoin de vérifier manuellement l'état d'un déploiement - peut-être lors du débogage ou de la gestion de cas limites rares.

Le Point de Terminaison de Statut (Utilisation Réduite)

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

Limite de Taux: 10 requêtes/secondes

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

• Statut.DÉPLOYEMENT – Le serveur est en cours de démarrage

• Statut.PRÊT – Le serveur est prêt pour les connexions des joueurs

• Statut.ERREUR – Quelque chose s'est mal passé pendant le déploiement

Bien que ce point de terminaison fonctionne, l'interroger de manière répétée pour des centaines de déploiements devient rapidement problématique. Vous épuiserez votre limite de taux et créerez une charge inutile sur l'API.

7. Implémentation des Webhooks pour une Surveillance de Niveau Production

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

• But: Les webhooks éliminent la surcharge d'interrogation, fournissent des notifications instantanées, qui sont essentielles pour créer un système de matchmaking réactif qui peut insérer les joueurs dans les jeux sans retard.

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

Événements de Webhook 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

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

• Pas de rétentions automatiques: Edgegap ne réessaye pas les livraisons de webhooks échouées. Si votre point de terminaison est hors ligne ou retourne une erreur, vous manquez cette notification. C'est pourquoi vous devez implémenter votre propre logique de rétentions et maintenir l'état des déploiements dans votre backend.

• Implémentez l'idempotence: Bien qu'Edgegap ne réessaye pas, les problèmes de réseau ou vos propres systèmes peuvent vous amener à traiter le même webhook plusieurs fois. Pensez à sécuriser votre gestionnaire de webhook pour traiter en toute sécurité les notifications en double sans corrompre vos données.

Meilleures Pratiques

• Utilisation des Webhooks pour Piloter l'Attribution des Joueurs: réduit le temps que les joueurs passent en attente et élimine la surcharge d'interrogation constante du statut. Pendant votre test de charge, mesurez à quelle vitesse vous pouvez passer de la création de déploiement à la connexion des joueurs. Voici un flux typique

  • Un match est formé, un déploiement est créé avec webhook_on_ready configuré

  • Les joueurs attendent dans un état de "match en démarrage"

  • Le webhook arrive à votre backend: "le déploiement XYZ est prêt"

  • Votre backend envoie immédiatement les détails de connexion aux joueurs qui attendent

  • Les joueurs se connectent et le match commence

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

• Évitez les interrogations agressives

8. Proposition de Plan d'Exécution du Test de Charge

• Objectif de cette étape : Créez un test de charge structuré et multi-étapes qui valide chaque aspect de votre pipeline de déploiement.

• But : Tentez de simuler une chronologie de votre lancement et du parcours des joueurs pour garantir que chaque composant fonctionne sous pression, comme le jour du lancement.

Phase 1 : Préparer les Clients de Test

Avant de pouvoir créer des déploiements, vous avez besoin de quelque chose pour les créer. Construisez des clients de test qui simulent le comportement de votre système de matchmaking :

·        Simulez un trafic de matchmaking réaliste imitant comment les joueurs se mettent en file d'attente pour les jeux 

·        Générez des demandes de déploiement depuis votre backend lorsque les matchs se forment 

·        Gérez les réponses des webhooks et mettez à jour l'état des matchs en conséquence 

·        Suivez 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 avec précision vos modèles d'utilisation des API.

Phase 2 : Exécuter la Montée en Puissance de la Création de Déploiement

Commencez à créer des déploiements progressivement, en respectant les limites de taux et en suivant une courbe d'arrivée réaliste. Cette phase teste votre capacité à monter en puissance lors de la création de déploiements au fur et à mesure de l'augmentation du trafic des joueurs :

• Commencez lentement et augmentez progressivement — évitez les pics instantanés qui ne reflètent pas le comportement réel des joueurs 

• Rester largement dans les limites de taux de l'API en répartissant les demandes uniformément 

• Suivez une courbe progressive qui simule l'arrivée organique des joueurs (plus de détails à la section 10) 

• Surveillez les erreurs de dépassement de limite et ajustez le rythme si vous rencontrez des réponses 429.

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

Phase 3 : Suivre l'Etat de Disponibilité des Déploiements

Au fur et à mesure que les déploiements se mettent en place, suivez quand ils sont prêts pour les connexions des joueurs :

• Confiez-vous principalement aux webhooks pour les notifications de disponibilité (comme discuté à la section 7)

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

• Mesurez le temps de préparation pour chaque déploiement — cela impacte directement le temps d'attente des joueurs 

• Suivez les taux d'erreur et enquêtez sur tout déploiement qui ne parvient pas à atteindre l'état READY.

Si vous constatezend detemps de déploiement ou des taux d'erreur élevés lors de cette phase, il vous faut investiguer avant de continuer. Ces problèmes s'amplifieront à mesure que vous monterez en charge complète en production.

Phase 4 : Simuler les Connexions des Joueurs (Si Possible)

Cette phase est optionnelle mais très précieuse. Une fois que les déploiements rapportent PRÊT, connectez réellement les joueurs simulés pour tester le pipeline complet :

• Lancez des bots clients de jeu qui se connectent en utilisant les informations de connexion du déploiement 

• Suivez le taux de succès des connexions — certains déploiements peuvent rapporter PRÊT mais échouer encore aux connexions 

• Mesurez la latence réseau depuis les emplacements des joueurs simulés jusqu'à leurs serveurs assignés 

• Vérifiez la fonctionnalité du jeu si vos bots peuvent exécuter des actions basiques en jeu.

Cette phase révèle des problèmes qui n'apparaissent que lors de connexions clients réelles. Si vous ne pouvez pas implémenter la simulation de client de jeu complet, testez au minimum la connectivité réseau brute vers chaque IP et port de déploiement.

Phase 5 : Exécuter le Nettoyage et la Validation

La phase finale valide la gestion du cycle de vie de votre déploiement :

• Terminez les déploiements au fur et à mesure que les matchs simulés se terminent (voir section 5)nbsp;

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

• Vérifiez la correction du cycle de vie en vérifiant que les déploiements traversent tous les états attendus 

• Analysez les données que vous avez collectées tout au long des phases pour identifier les goulets d'étranglement et les échecs.

Une phase de nettoyage réussie devrait montrer zéro déploiement orphelin et confirmer que votre système gère correctement l'intégralité de cycle de création-exécution-suppression à grande échelle.

9. Modéliser un Trafic de Joueur Réaliste

• Objectif de cette étape : Conception de modèles de test de charge reflétant avec précision comment les joueurs réels rejoignent les matchs du jeu et structurent vos déploiements de serveurs de jeu.

• But :

  Aligner avec des modèles de trafic réalistes pour produire des insights significatifs. Si votre test ne correspond pas à un comportement réaliste, vous ne découvrirez pas les problèmes potentiels réels lors du lancement.

Voici une vérité essentielle sur le test 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 vrai lancement. Vous ne faites que prouver que l'API peut rejeter vos demandes 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 joueurs réels n'arrivent pas tous à la même milliseconde 

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

• Sauter le nettoyage de déploiement : les matchs réels se terminent et libèrent de la capacité pour de nouveaux 

• Tester uniquement des rafales courtes : la charge de production est soutenue pendant des heures, révélant des problèmes que les tests courts manquent 

• Lancer des tests sans orchestration backend : votre système réel inclut une logique de matchmaking, des files d'attente et la gestion des états.

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

Ce qu'un Bon Test de Charge Simule

Un test de charge réaliste modélise ces comportements. Par exemple, alignez-vous sur des jeux de comparaison en utilisant SteamDB CCUs tracker. Par exemple, le succès massif de PEAK a toujours pris jours pour monter à son plus haut pic CCU, avec sa plus grande augmentation de 40 000 CCU réalisée sur une journée complète et pourtant une moyenne de 20 000 CCU par rapport à son pic ce jour-là.

• Taux d'arrivée des joueurs : les joueurs arrivent en premier peu à peu, puis arrivent par vagues aux heures de pointe.

• Fréquence de création de match :

  basée sur la rapidité avec laquelle votre faiseur de matchs peut former des groupes

• Cycle de vie complet des déploiements : création, disponibilité, connexions des joueurs, durée des matchs et nettoyage

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

• Répartition géographique : les joueurs viennent de différentes régions, affectant le placement des déploiements.

Quand vous modélisez ces facteurs, votre test de charge devient une véritable validation de votre préparation à la production plutôt qu'un simple test de stress d'API.

10. Exemples de Profils de Trafic

Comme mentionné précédemment, le scénario le plus probable sera de correspondre à un titre de comparaison dans le même genre et la portée du projet en utilisant SteamDB et d'appliquer un multiplicateur pour une sortie simultanée sur console (3-5x pour PlayStation, 1x pour XBOX).

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

Scénario A : Lancement Indépendant (200 Joueurs Simultanés)

Plan de test recommandé : Passez de 0 à 5 déploiements/minute en 10 minutes, puis maintenez pendant 60 minutes.

Scénario B : Titre Multijoueur de Taille Moyenne (2 000 Joueurs Simultanés)

Plan de test recommandé : Passez de 0 à 20 déploiements/minute en 20 minutes, puis maintenez pendant 90 minutes.

Scénario C : Grand Événement / Week-end Bêta (10 000 Joueurs Simultanés)

Plan de test recommandé : Passez de 0 à 50 déploiements/minute en 30 minutes, puis maintenez de 2 à 4 heures.

Implémentation d'une Courbe de Montée Réaliste

Quel que soit votre échelle, suivez un modèle de montée progressive comme celui-ci :

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

Cette courbe progressive simule :

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

• Montée en puissance du faiseur de match à mesure que les files d'attente se remplissent et que les matchs commencent à se former 

• Montée en puissance du provisionnement des déploiements à mesure qu'Edgegap échelonne la capacité pour répondre à la demande 

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

Ajoutez aussi un peu de variabilité à votre timing de déploiement. Ne les créez pas aux secondes exactes. Le matchmaking réel a une variance naturelle quant au moment où les matchs se forment.

11. Définition des Objectifs de Validation en Production

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

• But : Des métriques concrètes sont nécessaires pour déterminer si vous êtes prêt pour le lancement ou si vous devez effectuer de nouvelles optimisations.

Un test de charge réussi ne se limite pas à "fonctionner sans planter". Vous avez besoin d'objectifs de performance spécifiques qui définissent une expérience utilisateur acceptable. Voici les métriques clés que vous devez valider :

• Latence de création de match : Mesurez le temps que cela prend depuis "match formé" à "appel d'API de déploiement terminé". Les joueurs attendent pendant cette période, donc le maintien en dessous de 5 secondes garantit une bonne expérience utilisateur.

• Temps de disponibilité du déploiement : Cela 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 meilleur qu'un démarrage de 2 minutes.

• Taux de succès de connexion des joueurs : Au-dessus de 99% signifie que presque tous les joueurs se connectent avec succès à leur serveur attribué. Si vous constatez des échecs de connexion, recherchez s'il s'agit d'un problème réseau, d'un problème de serveur de jeu ou de détails de connexion incorrects fournis aux clients.

• Saturation des limites de taux de l'API : Vous devez compléter votre test de charge sans dépasser{