Emplacements mondiaux de l'Edge Cloud
Cibles de déploiement distinctes où un conteneur de serveur de jeu peut être planifié à la demande.

Conservez PlayFab. Votre système de matchmaking, votre économie, votre authentification et vos données de joueur (Player Data) restent exactement là où ils sont : seuls les serveurs bougent, et avec eux la facture des machines virtuelles Azure que vous payez pour la capacité en veille qui attend entre les pics de charge.
Supprimez le GSDK, conteneurisez la version que vous avez déjà et laissez une fonction Azure PlayFab se déployer sur Edgegap dès qu'un match est trouvé. L'orchestration hybride d'Edgegap associe des Private Fleets bare metal à notre réseau Edge Cloud de plus de 615 emplacements pour garantir la rentabilité de votre hébergement. Chaque déploiement Edge Cloud est dirigé vers le meilleur emplacement disponible au moment de la demande, mesuré à partir des joueurs présents dans le match.
Ce qui change (et ce qui ne change pas)
Une migration de serveurs de jeu multijoueurs PlayFab est un changement d'hébergement, pas un changement de backend. Voici à quoi vous attendre lors de votre migration.
Une analyse détaillée, fonctionnalité par fonctionnalité, est présentée à l'étape Étape 3 : Identifier et remplacer les fonctionnalités ci-dessous.
Ce qui reste inchangé
Votre netcode et transport
Edgegap ne touche jamais à votre transport, à votre sérialisation ou à votre boucle de tick. Le conteneur exécute le même binaire de serveur que vous construisez aujourd'hui.
Votre backend PlayFab
Les files d'attente et les règles de Matchmaking, les données des joueurs, l'économie, l'authentification, les classements et CloudScript restent tous dans PlayFab. Cette migration concerne les serveurs multijoueurs (Multiplayer Servers) et rien d'autre dans votre titre.
Votre flux de connexion client
Votre client reçoit toujours une adresse et un port et s'y connecte. Dans le pont documenté, il les lit toujours à partir des données de joueur PlayFab (PlayFab Player Data), exactement comme il le fait aujourd'hui.
Moteur, versions & CI
Même moteur, même version, même pipeline de build. Rien dans votre CI ne nécessite d'étape supplémentaire au-delà du push de l'image.
Qu'est-ce qui change
Le GSDK est disponible
Le SDK PlayFab Game Server s'intègre à votre binaire : le démarrage de l'agent, les rappels de disponibilité et de session, ainsi que les rapports d'état et de santé qu'il exécute en boucle. Edgegap ne nécessite aucun SDK serveur. Votre serveur lit son adresse IP publique et ses ports à partir des variables d'environnement lors du déploiement.
Un seul appel de déploiement remplace le pool de réserve
Au lieu de demander un serveur à partir de la capacité que vous avez provisionnée à l'avance, une fonction PlayFab Azure Function envoie une seule requête au point de terminaison de déploiement lorsqu'une partie est trouvée, et le déploiement est créé pour cette partie.
Les régions cessent d'être un facteur de décision d'achat
Vous n'avez plus besoin de dimensionner la capacité des machines virtuelles région par région. Chaque déploiement est placé au meilleur emplacement disponible sur le réseau Edge Cloud au moment de la demande, mesuré à partir des joueurs de la partie.
Le calcul de veille disparaît
Aucune cible de réserve à calculer, aucun seuil de pourcentage et multiplicateur à ajuster par région, aucune fenêtre de réduction d'activité, et aucun pool à maintenir actif entre les pics. La gestion de la capacité n'est plus de votre ressort : Private Fleet est redimensionné avec nous au rythme de l'évolution de votre courbe de trafic, et Edge Cloud ne nécessite absolument aucun pré-approvisionnement.
Calendrier prévu
Étape 1
Supprimez le SDK PlayFab Game Server : le démarrage de l'agent, les rappels de disponibilité et de session, ainsi que la boucle de rapport d'état et de santé.
~2 heures
Étape 2
Si vous livrez déjà une build de conteneur Linux, l'artefact reste inchangé. Les builds uniquement destinées à Windows nécessitent d'abord une build de serveur Linux, ce qui constitue la seule tâche véritablement importante de cette migration.
~30 min à 2 h
Étape 3
Le registre d'Edgegap est disponible gratuitement, ou conservez ACR, DockerHub, GitLab, etc.
~30 min.
Étape 4
Une règle match_found exécute une fonction Azure qui effectue le déploiement sur Edgegap, et chaque joueur reçoit l'adresse dans des données en lecture seule une fois que le serveur est prêt.
environ 1 jour
Étape 5
Déployez à l'échelle mondiale sur Edge Cloud, et réduisez éventuellement encore plus vos coûts grâce à un hébergement sans frais d'egress sur Private Fleets.
Déploiement instantané
Étapes de migration détaillées
Si vous cherchez à migrer vos serveurs de jeu hors de PlayFab Multiplayer Servers tout en conservant le reste de PlayFab, les étapes simples suivantes vous permettront d'être opérationnel en un rien de temps. Instructions complètes, y compris un exemple Unity fonctionnel : Exemple PlayFab Matchmaking avec Edgegap.
Avant de commencer, il est utile de bien comprendre ce qui est transféré et ce qui ne l'est pas.
Seuls les serveurs Multiplayer Servers sont déplacés : PlayFab conserve votre entremetteur (matchmaker), vos données de joueur (Player Data), votre économie et votre authentification, et Edgegap devient l'emplacement où s'exécute le serveur mis en correspondance. Edgegap est une API, sans SDK serveur.
Nous supposons que : vous utilisez actuellement PlayFab Multiplayer Servers, vous disposez d'un build de serveur de jeu fonctionnel, vous pouvez ajouter des règles d'automatisation dans votre titre, et vous avez un abonnement Azure pour les deux Azure Functions.
Étape 1 :
Edgegap ne nécessite pas de SDK serveur pour s'intégrer. La première étape consiste à supprimer le code qui initialise le SDK PlayFab Game Server dans votre serveur de jeu : l'appel de démarrage de l'agent, les rappels que vous avez enregistrés pour l'activation du serveur et l'attribution de session, les gestionnaires d'arrêt et de maintenance, ainsi que les rapports d'état de santé et des joueurs que l'agent attend en boucle. Rien ne les remplace. Sur Edgegap, votre serveur lit ce dont il a besoin à partir des variables d'environnement injectées lors du déploiement, y compris son adresse IP publique et son mappage de ports, et il est prêt pour les joueurs dès qu'il est en écoute. Si vous avez utilisé le wrapper GSDK plutôt qu'une intégration directe, il faut également le retirer, et la propre documentation de PlayFab indique que le wrapper « n'est pas destiné à une utilisation en production ».
Étape 2 :
Si vous exécutez déjà des builds de conteneurs Linux sur PlayFab, cette étape est plutôt une vérification qu'une reconstruction : confirmez que l'image se compile et démarre localement, puis poussez-la vers le registre gratuit d'Edgegap, ou conservez ACR, DockerHub, GitLab ou tout autre registre compatible OCI.
Si votre titre exécute des builds de VM Windows, vous devez d'abord disposer d'un build de serveur Linux. Cela représente un réel travail, mais les plugins dédiés d'Edgegap pour Unity, Unreal Engine et Godot vous aident à compiler l'image automatiquement une fois que vous avez une cible de serveur Linux.
Étape 3 :
Fonctionnalité GSDK | Équivalent Edgegap |
|---|---|
Game Server SDK (GSDK) | Aucun SDK serveur. Ports et variables injectés lors du déploiement. |
Builds et tailles de machine virtuelle | Applications et versions. Choisissez les vCPU et la mémoire par version, fractionnables à partir de 0,25 vCPU. |
Régions de build | Aucune configuration de région. Placement au moment de la demande au meilleur emplacement disponible sur le réseau Edge Cloud pour le calcul à la demande, Private Fleets sur bare metal pour la capacité réservée. |
Serveurs en veille et calcul de la veille cible | Mise à l'échelle automatique pour le calcul à la demande (Edge Cloud). Private Fleets sur bare metal pour une capacité persistante, redimensionnée mensuellement. |
Mise en veille dynamique et programmée | Non requis. Le basculement vers Edge Cloud est automatique. |
RequestMultiplayerServer | Un POST vers le point de terminaison de déploiement, à partir d'une fonction Azure sur la règle match_found, ou de votre backend. |
Matchmaker PlayFab | Inchangé, avec l'allocation de serveur désactivée sur la file d'attente. Une règle match_found déclenche le déploiement. |
Détails de connexion au serveur | Écrits dans les données de joueur en lecture seule de chaque joueur par une seconde fonction Azure une fois le serveur prêt, et lus par votre client. Votre serveur de jeu ne conserve aucun secret PlayFab. |
Journaux de serveur et serveurs archivés | Journaux de déploiement, API Deployment Status et Webhook de déploiement. |
Gestion des serveurs dans Game Manager | Tableau de bord Edgegap, API Deploy et Analytique et surveillance des déploiements. |
Travail de portage | Facultatif : connectez votre agent de codage au serveur MCP Edgegap. Il charge les compétences d'agent testées d'Edgegap pour votre moteur, puis crée ou vérifie votre image, la téléverse et déploie votre serveur, et chaque modification peut d'abord être prévisualisée sous la forme d'un essai à blanc (dry run). La compétence PlayFab configure la file d'attente, les deux fonctions Azure et la règle match_found de bout en bout. |
Étape 4 :
Les Private Fleets sont ce qui se rapproche le plus de la capacité que vous gérez aujourd'hui : des hôtes bare metal persistants et dédiés avec un hébergement sans frais de sortie.
La différence réside dans le travail qui les entoure. Il n'y a pas de cible de secours à calculer, pas de seuils ou de multiplicateurs par région à ajuster, et pas de fenêtre de réduction progressive. Vous redimensionnez la flotte chaque mois, et lorsqu'une Private Fleet est pleine, les déploiements basculent automatiquement sur Edge Cloud.
Prix
Découvrez comment l'orchestration d'Edgegap est plus rentable par rapport à votre facture actuelle de serveurs de jeu Multiplay (PlayFab Multiplayer Servers).
Les propres recommandations de PlayFab préconisent de dimensionner un pool de serveurs en veille en fonction du temps d'initialisation et du taux d'allocation, et précisent que les serveurs en cours d'initialisation et en veille sont facturés à votre titre.
PlayFab Multiplayer Servers | Edgegap | |
|---|---|---|
Capacité inactive | Facturée. Les serveurs en veille et en cours d'initialisation fonctionnent et sont facturés entre les pics | Non facturée sur Edge Cloud. Zéro déploiement actif coûte 0 $ |
Méthode de dimensionnement | Cible de serveurs en veille calculée à partir du temps d'initialisation et du taux d'allocation cible, par région | Rien à dimensionner sur Edge Cloud. Private Fleets ajustées mensuellement |
Mode de défaillance | Pénurie de serveurs en veille : les demandes de serveurs échouent lorsque la demande dépasse l'approvisionnement | Les déploiements sont créés par match, provisionnés à partir de zéro en 2 secondes, médiane, jusqu'à ce que le conteneur soit prêt |
Vous achetez un profil de machine sur PlayFab. Vous achetez de la puissance de calcul sur Edgegap.
PlayFab Multiplayer Servers | Edgegap | |
|---|---|---|
Unité | Taille de machine virtuelle choisie selon les cœurs, la RAM et le stockage, par région de build | Minute de vCPU, fractionnable à partir de 0,25 vCPU |
Granularité | Machines entières, plus la densité de serveurs par machine que vous gérez | Par déploiement, sans décisions de densité |
Tarif | Par taille de machine virtuelle, par région, selon la grille tarifaire publiée par PlayFab | 0,00115 $ par vCPU par minute dans le monde entier, tarif unique |
Une flotte dimensionnée pour les pics d'activité reste inactive la majeure partie de la semaine. L'orchestration hybride permet de maintenir un hébergement rentable en combinant des Private Fleets bare metal avec Edge Cloud à la demande.
PlayFab Multiplayer Servers | Edgegap | |
|---|---|---|
Capacité réservée | Pools de serveurs en veille que vous dimensionnez par région, ajustés avec des seuils et des multiplicateurs | Private Fleets bare metal, ajustées mensuellement selon l'évolution de la courbe de trafic |
Capacité à la demande | La veille dynamique multiplie la cible de serveurs en veille que vous avez configurée, jusqu'à votre nombre maximal de serveurs | Réseau Edge Cloud de plus de 615 emplacements, chaque déploiement se faisant sur le meilleur emplacement disponible au moment de la requête |
Effet net à des milliers d'utilisateurs simultanés (CCU) | Planification de la capacité en tant que tâche opérationnelle continue | 25 à 35 pour cent de moins que le cloud pur avec une répartition correctement optimisée. Modélisez-le dans le calculateur de prix |
Edgegap | Azure PlayFab | |
|---|---|---|
Orchestration | Orchestration hybride, aucun SDK de serveur de jeu requis : |
|
Infrastructure | Fournisseur unique :
| |
Matériel |
|
|
Emplacement |
|
|
Tarification |
| |
Évolutivité |
|
|
Intégration |
|
|
Assistance | 24h/24 et 7j/7 pour les clients, gratuite. Disponible sur Discord, Slack, e-mail |
|
Latence | Réduction moyenne de 58 % par rapport au cloud public (étude de cas Edgegap) |
|
Historique et expérience |
|

Clients
15 études de cas sont disponibles auprès de studios qui ont migré vers Edgegap depuis une autre plateforme.

Migration d'un jeu LiveOps pour solutioner la charge de travail DevOps
Découvrez pourquoi le tireur d'extraction VR n°1 est alimenté par l'hébergement et l'orchestration de serveurs de jeu d'Edgegap.
Étude de cas

Serveurs persistants qui "scale" & améliorent l'expérience des joeurs
Découvrez comment The Isle a amélioré l'expérience de ses joueurs grâce aux déploiements mondiaux de serveurs persistants d'Edgegap.
Étude de cas

Un MMO cosy migré en quelques jours grâce à l’orchestration d’Edgegap
Comment Qloud Games a migré l’hébergement des serveurs de jeu de Loftia chez Edgegap en moins de 24 heures et a lancé une bêta avec des milliers de joueurs.
Étude de cas

Guerre VR à grande échelle : Triangle Factory lance Forefront 1.0 sur Edgegap
Comment Triangle Factory a migré son jeu de tir en VR le plus ambitieux vers Edgegap et a lancé sa version 1.0 complète en toute confiance.
Étude de cas

Du Peer-to-Peer aux combats équitables : Bloody Bastards sur serveurs dédiés
Comment Tibith Ltd a migré Bloody Bastards, un succès mobile, du peer-to-peer vers les serveurs dédiés et le matchmaking d'Edgegap, garantissant que chaque match soit géré côté serveur.
Étude de cas

Comment Noodlecake propose le mode multijoueur tout en oubliant l'existence des serveurs
Comment Noodlecake a migré Super Flappy Golf vers l'orchestration automatisée d'Edgegap et s'est recentré sur le développement du jeu.
Étude de cas

Breachers migre vers Edgegap
Comment Triangle Factory a adapté son jeu de tir VR compétitif en 5v5 à une infrastructure conçue pour la précision qu'exige ce genre.
Étude de cas

Comment Blue Duck utilise les Fleets d'Edgegap pour l'orchestration de son MMO
Découvrez comment Blue Duck Studios utilise l'API Fleets d'Edgegap pour orchestrer les serveurs de son jeu de football.
Étude de cas

1047 Games sur Edgegap : une migration et un lancement fluides
Comment 1047 Games a migré Splitgate: Arena Reloaded vers Edgegap et a lancé Empulse sur son orchestration, avec un hébergement resté fiable tout au long.
Étude de cas

De l'orchestration homebrew à 50 000 joueurs du jour au lendemain
Comment Slipstream Games a réduit ses coûts de serveur de 50%, a diminué son ping de 200-250 ms à 100-110 ms et a lancé sur CrazyGames atteignant 50 000 joueurs en 24 heures.
Étude de cas

De la flotte à la demande : des serveurs dédiés pour un jeu de scooters
Comment iScoot est passé à une orchestration à la demande basée sur des instances, aboutissant à des serveurs dédiés 10 fois plus petits en terme de modèle de coûts
Étude de cas

Triangle Factory migre Hyper Dash chez Edgegap
Comment un jeu de tir en VR gratuit reste rapide, mondial et rentable grâce à une infrastructure à la demande qui s'adapte à ses joueurs.
Étude de cas
Découvrez l’impact de l’orchestration automatisée des serveurs de jeu d’Edgegap pour une expérience multijoueur impeccable.
Edgegap est l'expert de l'hébergement et de l'orchestration. Notre plateforme est conçue sur mesure pour vous aider à accélérer votre processus de développement, ce qui vous permet de vous concentrer sur ce dans quoi vous excellez : le développement.
Non. Cette migration ne déplace que les serveurs multijoueurs (Multiplayer Servers). Vos files d'attente et règles de matchmaking, vos données de joueur (Player Data), votre économie, votre authentification, vos classements et vos CloudScripts restent dans PlayFab et continuent de fonctionner exactement comme aujourd'hui. L'intégration repose sur deux fonctions Azure : une règle match_found exécute la première, qui déploie un serveur sur Edgegap à proximité des joueurs appariés, et Edgegap appelle la seconde lorsque le serveur est prêt, ce qui écrit l'adresse et le port dans les données en lecture seule de chaque joueur pour que le client puisse les lire. Votre serveur de jeu ne conserve aucun secret PlayFab. Nous publions l'ensemble sous la forme d'un exemple Unity fonctionnel, et la compétence PlayFab pour le serveur MCP d'Edgegap peut le configurer avec votre agent de codage.
Il disparaît et rien de propriétaire ne le remplace. Le démarrage de l'agent, les rappels de disponibilité et de session, le gestionnaire d'arrêt et la boucle de rapport d'état, tout s'en va. Sur Edgegap, votre serveur lit son adresse IP publique et son mappage de ports à partir des variables d'environnement lors du déploiement, et il est prêt dès qu'il est à l'écoute. Si vous avez effectué l'intégration via le wrapper GSDK de PlayFab plutôt que directement, cela disparaît également ; leur propre documentation indique que le wrapper « n'est pas destiné à être utilisé en production ».
Aujourd'hui, vous calculez une cible de mise en veille à partir du temps d'attente et du taux d'allocation, vous définissez le nombre maximal de serveurs par région, et vous ajustez les seuils et multiplicateurs de veille dynamique pour que le pool ne s'épuise pas, les serveurs en état d'attente et de veille restant à votre charge tout au long du processus. Sur Edge Cloud, il n'y a pas de pool : chaque match bénéficie d'un déploiement, provisionné à partir de zéro en 2 secondes, valeur médiane, mesuré jusqu'à ce que le conteneur soit prêt, avant le démarrage du moteur de jeu. Si vous souhaitez disposer d'une capacité qui vous appartient déjà, les Private Fleets vous l'offrent, dimensionnées mensuellement plutôt qu'ajustées par région.
C'est la seule chose sur cette page qui peut représenter un véritable travail, alors le voici clairement : Edgegap exécute des conteneurs Linux, donc un serveur uniquement sous Windows nécessite une build Linux avant toute autre chose. Pour la plupart des projets Unity et Unreal, il s'agit d'une cible de build et d'un passage sur le code spécifique à la plateforme. Si votre serveur dépend de bibliothèques exclusivement Windows, c'est un projet en soi, et cela nécessite un examen honnête de ce que cela implique pour votre architecture. C'est une discussion que nous serons ravis d'avoir : parlez à nos ingénieurs et nous travaillerons avec vous à la transition vers des instances de serveur de jeu sous Linux. Si vous livrez déjà des builds de conteneurs Linux sur PlayFab, rien de tout cela ne s'applique et votre artefact reste inchangé.
Oui. Les files d'attente, les règles, les tickets et l'expérience de matchmaking de vos joueurs restent inchangés, car PlayFab gère toujours le matchmaking. Deux choses changent : l'allocation de serveurs est désactivée sur la file d'attente, de sorte que PlayFab ne fait que créer la partie ; et au lieu de demander un serveur à partir de votre capacité allouée, la règle match_found exécute une fonction Azure qui envoie une requête unique au point de terminaison de déploiement d'Edgegap avec l'emplacement des joueurs, afin que le serveur soit déployé au plus près des joueurs présents dans cette partie. Si vous préférez tout consolider plus tard, le matchmaker sans code d'Edgegap est à votre disposition, mais rien dans cette migration ne l'impose.
Principalement à partir de la capacité pour laquelle vous cessez de payer pendant qu'elle attend. PlayFab facture les serveurs dans les états d'approvisionnement et d'attente, de sorte qu'un pool dimensionné pour votre taux d'allocation maximal fonctionne et facture à chaque heure creuse. Sur Edge Cloud, zéro déploiement actif coûte 0 $, et le calcul est de 0,00115 $ par vCPU et par minute, fractionnable à partir de 0,25 vCPU, plutôt qu'une taille de machine virtuelle que vous choisissez par région. À des milliers de CCU, une répartition correctement optimisée entre Private Fleets et Edge Cloud se situe de 25 à 35 % en dessous du cloud pur. Modélisez votre propre trafic dans notre calculateur de prix plutôt que de croire cette fourchette sur parole.
Méthodologie
Chaque métrique indique ce qui est mesuré, sur quelle période et ce qui est exclu. Les résultats de référence sont datés du test qui les a produits et ne sont pas reformulés en tant que chiffres actuels.
Où les serveurs peuvent fonctionner et combien nous en avons exploités.
Cibles de déploiement distinctes où un conteneur de serveur de jeu peut être planifié à la demande.
Emplacements où un studio peut réserver des hôtes Private Fleet pour son usage exclusif.
Nombre total de déploiements de serveurs de jeu orchestrés depuis février 2019, y compris les déploiements qui n'ont pas réussi à démarrer, selon la même méthode de calcul que nos concurrents.
La rapidité avec laquelle notre orchestration déploie un serveur, et ce qu'elle soutient en condition de test.
Démarrage à froid : provisionné à partir de zéro, et non alloué sur un serveur déjà en cours d'exécution. Mesuré jusqu'à ce que le conteneur soit prêt, avant le lancement du moteur de jeu.
Déploiements démarrés par seconde, en moyenne sur un test de référence continu de 60 minutes. C'est le taux standard pour chaque jeu des studios confirmés ayant du trafic en production ; des taux plus élevés sont disponibles sur demande.
Sessions simultanées atteintes sur de véritables conteneurs de serveurs de jeu, à raison de 100 joueurs par serveur.
Ce à quoi nous nous engageons contractuellement pour notre orchestration, et ce que les moniteurs enregistrent.
Garanti par notre SLA. Taux de disponibilité mesuré sur les 90 derniers jours : 99,999 %.
Fournisseurs de services cloud et de serveurs dédiés (bare-metal) sous contrat acheminant le trafic de production. Le basculement est automatique.
L'état des composants en direct est publié sur status.edgegap.com.
Une entrée par métrique : ce qui est mesuré, comment et sur quelle période.
Un emplacement correspond à une cible de déploiement distincte : un site de centre de données chez l'un de nos fournisseurs d'infrastructure, dans lequel un conteneur de serveur de jeu peut être planifié à la demande. Les sites ne sont comptabilisés qu'une seule fois, quel que soit le nombre de fournisseurs présents dans la même zone métropolitaine, et uniquement lorsqu'ils acceptent des déploiements.
Retour à la métrique ↑Comptabilisé séparément des plus de 615 emplacements Edge Cloud, qui correspondent à de la capacité cloud à la demande : un emplacement Private Fleet est un site où un studio réserve des hôtes pour son usage exclusif. Publié en direct sur la page Fleet Manager. Chaque hôte Private Fleet inclut 6 To de trafic sortant par mois.
Retour à la métrique ↑Comptabilisé comme le nombre total de déploiements enregistrés depuis février 2019, y compris les déploiements qui n'ont pas pu démarrer, selon la même méthode que celle utilisée par nos concurrents.
Retour à la métrique ↑Démarrage à froid : provisionné à partir de zéro, et non alloué sur un serveur déjà en cours d'exécution. Mesuré jusqu'à ce que le conteneur soit prêt, avant le lancement du moteur de jeu.
Retour à la métrique ↑L'orchestrateur a démarré de véritables conteneurs de serveurs de jeu en continu pendant 60 minutes, avec une moyenne de 40 déploiements démarrés par seconde sur l'heure complète, comptés au démarrage du déploiement plutôt qu'à l'état prêt. Mesuré sur plus de 550 sites et 17 fournisseurs en novembre 2023. Le test de référence a été réalisé pour un seul jeu. La capacité étant allouée par jeu, chaque jeu de la plateforme peut évoluer à ce niveau de manière indépendante et simultanée. 40 par seconde est le taux standard. Les studios qui ont besoin de plus peuvent planifier un taux plus élevé avec nous : lors d'un test de charge client en octobre 2026, les déploiements ont culminé à 70 par seconde, avec 85 en une seule seconde, via la même API et le même ordonnanceur de production que tous nos clients, sans impact mesurable sur les autres clients. Comment nous avons mené ce test.
Retour à la métrique ↑En novembre 2023, la plateforme a maintenu 40 déploiements de serveurs de jeu par seconde pendant 60 minutes, répartis sur plus de 550 sites et 17 fournisseurs, atteignant ainsi 14 millions de sessions simultanées à raison de 100 joueurs par serveur. Les serveurs de jeu étaient de véritables conteneurs ; les clients joueurs étaient simulés. Le benchmark a été réalisé pour un seul jeu. La capacité étant allouée par jeu, chaque titre présent sur la plateforme peut évoluer à ce niveau de manière indépendante et simultanée.
Retour à la métrique ↑La disponibilité est garantie à 99,99 % selon notre SLA et mesurée en continu sur cinq composants surveillés indépendamment : le registre de conteneurs, le tableau de bord, l'API publique, la documentation publique et le site Web. Le taux de disponibilité mesuré sur les 90 derniers jours s'élève à 99,999 %. Les données en direct sont publiées sur status.edgegap.com.
Retour à la métrique ↑Fournisseurs distincts sous contrat et acheminant le trafic de production, comptabilisés au niveau de l'entité juridique. Le basculement entre les fournisseurs est automatique ; c'est le principe fondamental de l'architecture multi-cloud.
Retour à la métrique ↑Ce qui est examiné, à quelle fréquence et ce qui a sa propre date.
Les chiffres de la plateforme présentés sur cette page sont examinés et actualisés chaque trimestre. Les indicateurs issus de sources en direct (disponibilité et déploiements de serveurs de jeu) comportent leur propre date de référence et sont mis à jour au fil des mesures. Les résultats des bancs d'essai sont datés du test dont ils sont issus et ne sont pas réactualisés en tant que données en temps réel.