Petite traduction par google . Espérons que toute leur modif de table ne nous ferons pas perdre no compte !
Ce qui suit est une description de la façon dont les statistiques backend fonctions pour BFBC2, ce qui se passe au cours de charge élevée, et ce que nous faisons pour le résoudre. Considérez cela comme un coup d'oeil "sous le capot» de BFBC2.
Aperçu du système
Lors de la lecture en ligne, tous les clients de jeu et des serveurs de jeux sont en permanence connectés à des serveurs backend du jeu.
Il ya un backend distinct pour chacune des versions de PC/PS3/360 BFBC2.
Un backend est divisé en deux parties - un groupe de machines qui se déplacent d'un logiciel personnalisé, et une base de données. La base de données n'est pas directement accessible par les clients de jeu / serveurs, ils ne peuvent l'atteindre en envoyant des requêtes à la partie des logiciels personnalisés, qui dans les pourparlers se tourner vers la base de données.
Chaque base de données est un ensemble de machines qui fonctionnent avec Oracle 9i RAC permis.
Il ya quelques modules dans le backend, et quelques tables dans la base de données, qui sont partagés entre plusieurs plates-formes / titres. Ces processus sont généralement assez faible intensité. Cependant celles-ci doivent être pris en charge si l'on veut effectuer des modifications à la configuration physique des machines qui exécutent le backend.
Stats
Une stat est un identifiant court avec une valeur d'accompagnement. Stats sont suivis pour chaque joueur, et ils sont enregistrés entre les sessions de jeux. Pour BC2 il ya environ 2000 valeurs uniques stats. Certaines des statistiques ont un sens direct - votre score actuel avec un kit spécifique, le nombre de tués avec une arme spécifique et ainsi de suite - alors que les autres stats n'ont pas de sens de leur propre chef et de suivre votre progression vers les différentes réalisations de trophées, épingles et insignes.
Les statistiques sont conservées dans un couple de grandes tables dans la base de données Oracle.
client du jeu et les statistiques
Le client du jeu ne fait que lire la base de données statistiques, il n'écrit jamais.
Stats lit arriver à deux reprises: quand un joueur se connecte, et quand un joueur sort d'un serveur vers le menu principal. Le client dispose d'un cache local de toutes les stats. Lorsque l'un des deux événements précédents se produisent, le client demande un jeu de stats poignée (par exemple l', le score total du joueur et du cumul des temps de jeu en ligne). Si aucune de ces statistiques sont différentes des valeurs mises en cache localement, le client du jeu s'éteint et saisit toutes les statistiques (environ 2000 valeurs).
Le client du jeu utilise ces statistiques pour afficher les informations dans le menu principal. Il n'est pas utilisé dans le jeu en multijoueur.
Serveur de jeu et les statistiques
Le serveur de jeu lit et écrit sur la base de données statistiques.
Quand un joueur entre un serveur, le serveur demande environ 1000 de stats pour ce joueur de la base de données. Tout ce qui a à voir avec les statistiques et les rangs est contrôlée par le serveur (par exemple, où les armes sont débloquées pour un joueur en particulier).
Le serveur écrit en arrière stats d'un joueur lorsque le joueur quitte le serveur. En outre, les statistiques de tous les joueurs sont écrites dans la base de données à la fin de chaque tour. Il s'agit de réduire au minimum le risque que les progrès du joueur est perdue à cause d'un plantage du serveur. Lors de l'écriture stats, le serveur va écrire que ces statistiques qui ont changé. En outre, si possible, le serveur va exécuter des commandes comme "ajouter 3 à stat nommé ABCD» plutôt que d'écrire "27 à stat nommé ABCD". Cela minimise le risque que tous les bogues dans les communications code ou le réseau de l'problèmes stats piétiner; le pire qui peut se produire est que la stat n'est pas augmenté, il ne sera pas abaissé ou mis à zéro par inadvertance.
Habituellement, le client du jeu sera d'écrire beaucoup moins de 1000 stats. Je n'ai pas de chiffres sous la main, mais peut-être 100 stats sont généralement mis à jour après qu'un joueur a joué une ronde complète.
scénarios de charge élevée et le backend
Normalement, la base de données répond aux logiciels personnalisés de lecture / écriture des requêtes très rapidement. La base de données peut répondre aux requêtes d'un couple de clients jeu / serveurs en parallèle, si il ya trop de demandes faites à la fois, de nouveaux sont mis dans une file d'attente. délai normal pour la récupération des stats 2000 est d'environ une seconde. Demander 2000 stats prend du temps un peu plus que de demander stats 1000 - probablement deux fois plus long. La base de données complète de la file d'attente des entrées-up le plus rapidement possible.
Les demandes ne viennent pas dans un flux constant toutefois. Parfois, de nombreux serveurs et les clients demandent des données statistiques à peu près au même moment. La base de données sera alors de service certaines de ces demandes un peu plus lent que d'habitude.
La base de données est la plus faible partie de BFBC2, c'est le logiciel personnalisé peut gérer plus de joueurs d'être actif en même temps, que la base de données peut.
Si les clients / serveurs font beaucoup de demandes à la base de données sur une longue période de temps, puis l'arriéré de demandes en attente de la base de données deviendra de plus en plus. Lorsque la file d'attente est si longue que la base de données est incapable de requêtes de service en 10 secondes, le logiciel personnalisé renoncer à ces requêtes et répondre avec une erreur à ces clients / serveurs.
scénarios de charge élevée et le client du jeu / serveur
Avec ce qui précède à l'esprit, imaginons ce qui se passe lorsque l'augmentation du nombre de joueurs simultanés.
Au début, il n'y a pas beaucoup de joueurs. La base de données prendra en charge toutes les demandes rapidement et sa file d'attente est presque vide tout le temps.
Comme le nombre de joueurs augmente, la base de données sera toujours en mesure de faire face à la plupart des demandes. Cependant, il arrive beaucoup de serveurs / clients qui arrivera à effectuer des requêtes stat à peu près au même moment. Cela provoque la file d'attente pour remplir un peu plus que d'habitude. Certaines de ces questions sera alors le temps quand ils ont frappé le seuil de 10 secondes. Puisque les clients demandent normalement plus de données, il est généralement la demande du client de jeu qui sont atteints en premier.
Si la demande du client de jeu tombe en panne, le client du jeu tente de récupérer de stats pour 10 secondes ou 20 - et laissent tomber, et le menu principal du jeu diront que le joueur est de rang 1 et a une note de zéro etc
Comme la charge augmente en outre, le serveur de jeu des requêtes de lecture échouera également plus souvent. Lorsque le serveur de jeu des requêtes de lecture échoue, les joueurs qui sont touchées joueront avec le rang 1 et pas de statistiques liées déverrouille. Lorsque cela se produit, le serveur de jeu ne sera pas enregistrer et écrire le progrès pour les acteurs concernés soit.
Enfin, avec une charge très élevée, toutes les demandes des clients et serveurs de jeu jeu va échouer.
charge élevée par rapport à la charge trop élevée
Une chose importante à noter à propos des systèmes en ligne et de charge, est que la charge ne se comporte pas comme vous le feriez intuitivement y attendez. Habituellement, il se lève lentement ... jusqu'à ce qu'il arrive à un certain point, et puis tout s'emballe découle de contrôle et d'horreur. Il ya plusieurs raisons à cela.
Le premier est le facteur humain: Lorsque la charge est à un niveau tel que les statistiques ne sont demandes par intermittence, il apparaît au lecteur comme il / elle a perdu toute sa progression, mais chacun connexion / déconnexion (en cas de non- Statistiques dans le menu principal) ou en débranchant / rebranchant (dans le cas de pas de statistiques dans le jeu) a un% de chance d'obtenir des statistiques de retour. Les gens vont alors naturellement faire plus et plus jusqu'à ce qu'ils soit obtenir des statistiques, ou sont frustrés suffisant pour abandonner. Ce comportement provoque plus de charge sur le serveur que sur le comportement normal gameplay, ce qui aggrave le problème global.
Un autre peut être dans le code; client de jeu parfois / code serveur de jeu est écrite pour réessayer une ou deux fois lorsque l'opération échoue. C'est une bonne chose quand le serveur n'est pas sous une charge élevée - après tout, l'erreur peut être due à un accident de parcours momentanée. Toutefois, lorsque la charge est élevée ce qui fera qu'aggraver le problème (exactement de la même manière que le "facteur humain par exemple").
Il ya aussi des choses qui se passent en arrière-plan sur les bases de données - comme les sauvegardes, ou régulièrement maintenance programmée / emplois traitement des données.
Cela signifie que certains systèmes en ligne peut sembler fonctionner très bien, avec une charge constante, et puis quelque chose se passe et en quelques minutes, ils paralysé.
Comment bien se comporter le système est dépend de ce que les fonctions qu'il exerce, et les comportements des utilisateurs du système.
logiciel de BFBC2 backend personnalisé est bien comportés dans la plupart des égards. La base de données souffre un peu des problèmes décrits ci-dessus - entre l'étape de "joueurs ne sont parfois pas se stats" et "les joueurs ne sont jamais obtenir stats" est plus petit que la théorie serait prévoir.
Un examen plus attentif à la base de données elle-même
D'une certaine façon la base de données statistiques utilisées pour traiter les joueurs beaucoup plus en arrière quand il a lancé que maintenant. En d'autres termes, lectures / écritures contre la base de données prend plus de temps pour terminer. Il ya deux raisons principales à cela.
* Il ya stats des joueurs beaucoup plus dans la base de données maintenant que l'époque où nous avons commencé. Bases de données sont bonnes requêtes et l'entretien comme «Donne-moi le contenu de l'utilisateur avec l'ID = 1234, il est quelque part dans cette immense table", mais les performances ne descendent que dans les tableaux croître en taille.
* Les tableaux eux-mêmes deviennent fragmentés. Plusieurs années et il ya plusieurs jeux, lorsque les administrateurs de base de la configuration de base de données conçu pour le système, ils ont demandé à ce que les priorités étaient la base de données. La réponse a été - les performances d'exécution; la base de données doit être configuré pour être en mesure de desservir le plus grand nombre de lectures / écritures par seconde que possible. Un compromis délibéré de la configuration la plus performante, ils pourraient créer, c'est que la base de données serait d'acquérir progressivement de petits trous dans elle. Ces lacunes ne sont pas récupérés automatiquement. Le montant de "perdu" l'espace dans la base de données augmenterait avec le temps, et après un certain temps l'espace perdu entraînerait des pertes de performance (en raison de caches disque ne sont pas aussi efficaces plus). Ce sont triés par la mise hors ligne de base de données une fois tous les deux mois et la reconstruction - ainsi évincer toutes les lacunes. Toutefois, pour une raison quelconque de ces reconstructions régulières n'ont pas été se passe de tout titre BFBC2.
Définir le problème
Le problème que nous aborderons est le suivant: la population joueur actuel souffre de coupures de stats. Cela ne devrait pas se produire. Stats doit être fiable à peu près le nombre de joueurs que nous avons maintenant, plus un peu de hauteur. Nous n'essaierons pas de le faire gérer 100,000 utilisateurs simultanés sur un moteur simple.
S'attaquer au problème
On peut essayer de faire les accès base de données individuelles plus rapidement.
Prenant la base de données hors ligne, et reconstruire des tables.
Ce qui est certain, pour vous aider. C'est aussi la première chose que nous ferons. (Et nouveau calendrier reconstruit chaque fois que nécessaire à l'avenir.)
Faire des tailles de cache disque de plus.
La mémoire est plus rapide que le disque, donc si plus de la base de données est conservée en mémoire, puis accède ira plus vite.
Le PC et 360 groupes de base de données ont autant de mémoire que c'est possible. Le cluster PS3 a une capacité de plus de mémoire que.
Nous allons l'ajouter.
Repenser les tableaux.
Le tableau de présentation n'est pas conçu spécifiquement pour BFBC2, la conception même est utilisé par de nombreux autres titres d'EA. Modification de la conception permettrait d'améliorer la performance de la plupart des demandes par un peu juste. Cependant, le temps nécessaire pour obtenir une telle modification en œuvre, tester, et de vivre est beaucoup trop long.
Nous allons donc ne pas le faire.
Ajout de plus de machines aux clusters de bases de données.
On pourrait penser que doubler le nombre de machines dans un cluster de base de données pourra également doubler les performances d'un cluster. En réalité, toutes ces machines ont besoin de coordonner leurs travaux avec les autres. Par conséquent, en ajoutant plus de machines permet parfois seulement. Dans certains cas, la performance se fait pire.
Nous allons donc ne pas le faire.
Le passage à une version plus récente base de données Oracle ou d'une autre tout à fait.
Encore une fois, le délai pour ce faire à un système de vie est beaucoup trop long.
Nous allons donc ne pas le faire.
Ou on peut réduire le montant de base de données d'accès.
clients jeu Making demande moins de stats.
Le client du jeu fait déjà un petit chercher avant de faire un plein fetch (du score de cas / heure ou quelques autres statistiques ont changé). Si le client ne met pas à jour toutes les statistiques dans son cache, le menu principal ne sera pas en mesure de montrer la progression du joueur en jeu correctement. Il est peut-être possible de diviser les statistiques aller chercher en deux parties - une partie pour montrer les choses les plus importantes dans le menu principal (dans le cas des PC BC2, les éléments statistiques liés à l'écran principal), et une autre partie pour afficher tous les les réalisations et de trophées, etc
Il est à l'étude.
Rendre les statistiques de jeu de cache des serveurs pour les joueurs.
Les serveurs pourraient avoir un cache comme les clients de jeu, mais stats cache pour beaucoup de joueurs différents. Cela permettrait aux gens qui jouent quasi-exclusivement sur un seul serveur. Il est douteux que cela ferait une différence (je n'ai pas de statistiques à ce sujet, il suffit de deviner).
Nous ne le ferons pas.
Rendre les serveurs de jeu demande moins de stats.
Récupérer moins de stats fera le serveur de jeu en mesure d'évaluer la progression du joueur complet.
Nous allons donc ne pas le faire.
Faire écrire les serveurs de jeu moins de stats.
Si les serveurs de jeu écrira stats au serveur à chaque tour Nième au lieu de chaque tour, il y aurait alors moins de stats unique écrite. Il ya un compromis ici - est-il un risque que les joueurs perdent leur progression en raison de pannes de serveur? - Mais N = 2 ou N = 3 permet à la fois des risques et l'impact très faible.
Nous avons déjà mis en œuvre ce changement pour les deux consoles, et la mettre en œuvre pour PC.
Une fois un ensemble de changements est en place, nous serons alors réévaluer la situation. Etc
