Terminologie
Termes à connaître concernant la mise à l’échelle des serveurs en attente.- Target Standby : également appelée Standby Target ou Standing by target, il s’agit d’une valeur définie par la plateforme qui spécifie le nombre cible de serveurs en attente à maintenir disponibles pour éviter l’épuisement du pool de serveurs en attente.
- Target Standby Floor : mesure configurable par le développeur du jeu qui représente la quantité minimale de serveurs maintenus inactifs pour répondre à la demande de nouveaux serveurs de jeu.
- Actual Standby : quantité de serveurs en attente signalée par la plateforme Multiplayer Servers; ses valeurs diffèrent selon que Dynamic Standby est activé ou désactivé.
- Pre-propping : Azure et PlayFab doivent créer la machine virtuelle, initialiser son système d’exploitation et configurer son environnement. PlayFab effectue cette activité de pré-préparation avant que la machine virtuelle ne soit attribuée à un client et facturée.
- Propping : les actifs des serveurs de jeu doivent être chargés, et l’application du serveur de jeu elle-même a souvent besoin d’un certain temps pour se préparer à accueillir les joueurs.
- Standing by : pour répondre immédiatement à la demande de serveurs multijoueurs, certains serveurs sont maintenus inactifs et prêts en permanence pour les joueurs.
Configuration de la cible de serveurs en attente
Vous configurez les cibles de serveurs en attente par build et par région. En général, vous devez définir le niveau de serveurs en attente proportionnellement au temps de préparation et au taux d’allocation cible : Standing by Target = (Propping Time + Server time to standing by) * Target Allocation Rate Par exemple, prenons un serveur Linux dont la préparation prend 100 secondes et un jeu pour lequel on prévoit jusqu’à un serveur alloué toutes les 5 secondes (0,2 serveur/seconde). Un pool de 100 * 0,2 = 20 serveurs en attente prendra en charge cette build de façon stable. Au bout de 100 secondes, 20 serveurs auront été consommés, mais il y aura eu le temps d’en préparer 20 autres. Lors de l’appel de l’APIRequestMultiplayerServer, il est important d’indiquer toutes les régions acceptables pour l’expérience des joueurs. Si la région 1 n’a pas de serveur en attente disponible, la région 2 est sollicitée, et ainsi de suite pour toutes les régions que vous avez configurées.
Avantages de la mise à l’échelle
Voici un récapitulatif des avantages de la mise à l’échelle :Méthodes de mise à l’échelle
PlayFab offre plusieurs mécanismes pour déterminer quand et comment mettre à l’échelle vos serveurs. Les développeurs de jeux ont la possibilité de :- Configurer des seuils minimal et maximal
- Personnaliser les configurations de mise à l’échelle selon les profils de build de serveur, tels que (a) les types d’instance, (b) la taille de machine virtuelle ou (c) les régions
- Gérer facilement les modifications depuis le portail des développeurs ou depuis l’API RESTful Multiplayer Servers
- Surveiller les métriques de mise à l’échelle dans les graphiques de serveurs et d’utilisation
- Par défaut
- Planifiée
- Dynamique
Pour tirer pleinement parti de l’ensemble des options de mise à l’échelle, vous devez d’abord comprendre les concepts clés et la terminologie suivants.
Concepts clés
- Les mécanismes de mise à l’échelle contrôlent le nombre de serveurs en attente disponibles
- Les serveurs en attente sont des serveurs alloués sur des machines virtuelles, sans joueurs actifs connectés. Ils se mettent à accepter les connexions des joueurs en réponse à l’appel d’API RequestMultiplayerServer, et passent à un état d’arrêt lorsque le processus du serveur de jeu se termine
- Les mécanismes de mise à l’échelle s’appliquent individuellement à chaque région d’une build
- Chaque configuration de mise à l’échelle est représentée par un remplacement de région
