DICE reboot server 25 au 28/01

[Kraken 22]

JV.com annonce ça !?

Nous allons arrêter les server pour quelques heures pour une maintenance sur toute les plateforme.'360/PS3/PC)

L'objectif est d'améliorer les performances du système de statistiques, de réduire ou d'éliminer les pannes de stats.

Zh1nt0 (community manager) vous en dira plus Lundi avec des précisions sur les horaires et les temps d’arrêt

Vous êtes au courant ?

[las63 0]

Deja le 18 ils avaient trouvé le probleme pour les stats et devaient rebooter les serveurs ps et xbox. Apres si la manipe n'a pas trop marché et que les joueurs toute plateforme en profiteront pourquoi pas mais sur le twitte a Zh1nto rien de signalé donc on va attendre aujourd'hui pour confirmer les dire de JV.com qui n'est plus une ref dans le jeux video depuis un certain moment

Et merci pour l'info

[las63 0]

voila la reponse

On Tuesday the 25th of January we are going to do a bit of maintenance work on the Xbox 360, Playstation 3 and the PC during these hours:

2:00 am PDT - 5:00 am PDT

5:00 am EST - 8:00 am EST

10:00 GMT - 13:00 GMT

11:00 CET - 14:00 CET

The purpose is to improve performance of the stats system, to reduce/eliminate stats outages. We're very sorry for the inconvenience.

Mikael Kalms from DICE posted a great thread on the stats issues on the EA UK forums. Check it out right here

[gobfredo 0]

une bonne chose ( si cela règle vraiment le problème )

[crazyfred29 0]

Merci, de m'avoir mi au parfum j'étais pas au courant. J'aurais été comme un con...

Moi je dit cette maintenance va faire un bien fou au serveurs, et peut être réparé les quelque bug qui ennuis tout le monde.

[Spidersnow 7]

bonne nouvelle, de toute façon a cette heure la je suis en cours ...

[Butcher44 0]

Salut, quelle merde moi je dis, je viens de me connecter ce matin et impossible de jouer bien sur... Si cela dure jusqu'au 28 entre les tranche horaire 10h-13 je vais les tuer lol, ce sont mes seul jour de congé après mon blocus et mes exam... Quelqu'un sait si il y a une garantie que les comptes ne seront pas perdu ou que l'on ne perde pas nos state ?

[DaRk 0]

Moi j'ai juste eux le temps de jouer 10 min ce matin

[las63 0]

il n'y aura pas de perte de stats

[Rian 0]

Bonjour,

Je ne pense pas qu'on perde quoi que se soit, car ils doivent aussi faire une backup avant de mettre leur nouveau système.

Savez vous si ils ont commence a l'heure prévu ? Ont-ils deja fait des reboot comme ca ? Si oui, ils ont toujours tenu leur horaires de rétablissement ?

Merci

[Butcher44 0]

Pour le backup je pense aussi mais je voulais être rassurer lol, merci . Je ne sais pas si il tienne leur horaire mais il faut bien pensé qu'il y aura des retards et surtout moins de serveur et de joueur le temps que tout soit ok.

Je joue cette aprem je vous direz quoi...

[Rian 0]

Intéressant le lire le probleme plus en details et voir les solutions.

What follows is a description of how the stats backend functions for BFBC2, what happens during high load, and what we are doing to resolve it. Consider it a peek 'under the hood' of BFBC2.

System overview

When playing online, all game clients and game servers are permanently connected to the game's backend servers.

There is a separate backend for each of the PC/PS3/360 versions of BFBC2.

A backend is split into two portions - one group of machines which run some custom software, and a database. The database is not directly accessible by game clients/servers; they can only reach it by sending requests to the custom software portion, which in turn talks to the database.

Each database is a cluster of machines which run Oracle 9i with RAC enabled.

There are a few modules in the backend, and a few tables in the database, which are shared between multiple platforms / titles. Those are generally rather low-intensity processes. However those have to be cared for if one wants to perform changes to the physical configuration of the machines that run the backend.

Stats

A stat is a short identifier with an accompanying value. Stats are tracked for each player, and they are saved between game sessions. For BC2 there are approximately 2000 unique stats values. Some of the stats have a direct meaning - your current score with a specific kit, number of kills with a specific weapon and so on - whereas other stats are meaningless on their own and track your progress toward various achievements/trophies, pins and insignias.

The stats are kept in a couple of big tables in the Oracle database.

Game client and stats

The game client only reads from the stats database; it never writes.

Stats reads happen on two occasions: when a player logs in, and when a player exits from a server back to the main menu. The client has a local cache of all stats. When one of the two previous events occur, the game client requests a handful stats (for instance the, the player's total score and accumulated online playtime). If any of those stats are different from the locally cached values, the game client goes out and grabs all stats (approximately 2000 values).

The game client uses these stats to display information in the main menu. It is not used in-game in multiplayer.

Game server and stats

The game server reads and writes to the stats database.

When a player enters a server, the server requests approximately 1000 stats for that player from the database. Anything that has to do with stats and ranks is controlled by the server (for instance, which weapons are unlocked for a specific player).

The server writes back a player's stats when the player leaves the server. Also, all players' stats are written to the database at the end of each round. This is to minimize the risk that player progress is lost because of a server crash. When writing stats, the server will only write those stats that have changed. In addition, whenever possible the server will issue commands like "add 3 to stat named ABCD" rather than "write 27 to stat named ABCD". This minimizes the risk that any bugs in the code or network communications problems will trample stats; the worst that can occur is that a stat is not increased, it will not get lowered or set to zero inadvertently.

Usually the game client will write a lot less than 1000 stats. I don't have figures at hand, but perhaps 100 stats are usually updated after a player has played a full round.

High load scenarios and the backend

Normally the database responds to the custom software's read/write queries very quickly. The database can service requests from a couple of game clients/servers in parallel; if there are too many requests made at once, new ones are put into a queue. Normal turnaround time for retrieving 2000 stats is approximately a second. Requesting 2000 stats takes a bit more time than requesting 1000 stats - probably about twice as long. The database completes the queued-up entries as quickly as it can.

The requests do not come in a steady flow however. Sometimes many servers and clients will ask for stats data at nearly the same time. The database will then service some of those requests a bit slower than usual.

The database is the weaker portion of BFBC2; that is, the custom software can handle more players being active simultaneously, than the database can.

If the clients/servers are doing a lot of requests to the database over a long period of time, then the backlog of queries in the database's queue will get longer and longer. When the queue is so long that the database is unable to service queries in 10 seconds, the custom software will give up on those queries and respond with an error to those clients/servers.

High load scenarios and the game client/server

With the above in mind, let's imagine what happen when the number of simultaneous players increases.

At first, there are not a lot of players. The database will handle any requests quickly and its queue is nearly empty all the time.

As the number of players go up, the database will still be able to keep up with most requests. However, occasionally a lot of servers/clients will happen to perform stat requests at nearly the same time. This causes the queue to fill up a bit more than usual. Some of those queries will then time out when they hit the 10 second cutoff. Since clients normally request more data, it is usually the game client's requests that fail first.

If the game client's request fails, the game client will attempt to retrieve stats for 10 or 20 seconds - and then give up, and the game's main menu will claim that the player is Rank 1 and has zero score etc.

As the load increases further, the game server read requests will also fail more often. When game server read requests fail, the players which are affected will play with rank 1 and no stats-related unlocks. When this happens, the game server will not record & write back progress for the affected players either.

Finally, with a really high load, all requests from game clients & game servers will fail.

High load versus too high load

One important thing to notice about some online systems and load, is that the load does not behave like you would intuitively expect it to. Usually it rises slowly... until it gets to a certain point, and then it all spirals out of control and horror ensues. There are several reasons for this.

One is the human factor: When the load is at such a level that stats requests are failing intermittently, it appears to the player like he/she has lost all his/her progression, but either logging in/out (in the case of no stats in the main menu) or disconnecting/reconnecting (in the case of no stats in the game) has a % of chance to get stats back. People will then naturally do this over and over until they either get stats, or are frustrated enough to give up. This behaviour will cause more load on the backend than normal gameplay behaviour, which worsens the problem overall.

Another can be in the code; sometimes game client/game server code is written to retry a couple of times when an operation fails. This is a good thing when the backend is not under high load - after all, the error might be due to a momentary hiccup. However, when the load is high this will make the problem worse (in just the same way as the "human factor example").

There are also some things happening in the background on databases - like backups, or regularly scheduled maintenance / dataprocessing jobs.

This means that some online systems can seem to be running fine, with a steady load, and then something happens and within minutes they grind to a halt.

How well-behaving the system is depends on what functions it performs, and the behaviours of the users of the system.

BFBC2's custom backend software is well-behaved in most respects. The database suffers a bit from the problems described above - the step between "players are occasionally not getting stats" and "players are never getting stats" is smaller than theory would predict.

A closer look at the database itself

Somehow the stats database used to handle considerably more players back when it launched than now. In other words, reads/writes against the database takes more time to complete. There are two main reasons for this.

There are stats for much more players in the database now than back when we started. Databases are good and servicing requests like, "give me the contents for user with ID=1234, it is somewhere in that huge table", but performance does go down as the tables grow in size.

The tables themselves are becoming fragmented. Several years and several games ago, when the database administrators designed the database setup for the system, they asked what the priorities were for the database. The response was -- runtime performance; the database should be setup to be able to service as many reads/writes per second as possible. One deliberate tradeoff of the highest-performance setup they could create was that the database would gradually acquire small gaps in it. These gaps would not get reclaimed automatically. The amount of "lost" space in the database would grow over time, and after a while the lost space would result in performance loss (due to disk caches not being as efficient anymore). This is sorted out by taking the database offline once every couple of months and rebuilding it - thereby squeezing out all the gaps. However, due to some reason these regular rebuilds have not been happening for any BFBC2 title.

Defining the problem

The problem we will tackle is the following: the current player population is suffering from stats outages. That shouldn't be happening. Stats should be reliable with roughly the player numbers that we have now, plus a bit of headroom. We will not attempt to make it handle 100.000 concurrent users on a single backend.

Tackling the problem

One can attempt to make individual database accesses faster.

Taking the database offline, and rebuilding the tables.

This is certain to help. That is also the first thing that we will do. (And schedule new rebuilds whenever necessary in the future.)

Making disk cache sizes larger.

Memory is faster than disk, so if more of the database is kept in memory then accesses will go faster.

The PC and 360 database clusters have as much memory as is possible. The PS3 cluster has room for more memory though.

We will add it.

Redesigning the tables.

The table layout is not designed specifically for BFBC2; the same design is used by many other EA titles. Changing the design would improve performance for most requests by a fair bit. However, the time required for getting such a modification implemented, tested, and live is far too long.

We will therefore not do it.

Adding more machines to the database clusters.

One might think that doubling the number of machines in a database cluster will also double the performance of a cluster. In reality, all those machines need to coordinate their work with each other. Therefore, adding more machines only helps sometimes. In some cases, performance actually gets worse.

We will therefore not do it.

Moving to a newer Oracle version or another database altogether.

Again, the turnaround time for doing this to a live system is far too long.

We will therefore not do it.

Or one can reduce the amount of database accesses.

Making game clients request fewer stats.

The game client is already doing a small fetch before doing a full fetch (in case score/time or a couple other stats have changed). If the client doesn't update all the stats in its cache, the main menu will not be able to show the player's ingame progression correctly. It is perhaps possible to split the stats fetching into two portions - one portion for showing the most important stuff in the main menu (in the case of BC2 PC, the stats-related items in the main screen), and another portion for showing all the achievements/trophies etc.

It is under consideration.

Making the game servers cache stats for players.

The servers could have a cache like the game clients, but cache stats for many different players. This would help with people who play near-exclusively on one server. It is doubtful if it would make a difference (I don't have statistics on this, just guessing).

We will not do it.

Making the game servers request fewer stats.

Fetching fewer stats will make the game server unable to evaluate the full player progression.

We will therefore not do it.

Making the game servers write fewer stats.

If the game servers would write stats to the backend at each Nth round instead of at each round, then there would be fewer unique stats written. There is a tradeoff here - is there a risk that players lose their progression due to server crashes? - but N=2 or N=3 keeps both risk and impact very small.

We have already implemented this change for both consoles, and will implement it for PC.

Once one set of changes is in place, we will then reassess the situation. Etc.

SOURCE : http://forums.electronicarts.co.uk/battlefield-bad-company-2-pc/1387445-stats-system-performance-perspective.html

[wolfry 14]

ah bah voilà qui explique mon incapacité a me log ^^

logiquement fini, mais sa...

[Butcher44 0]

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

[Rian 0]

La traduction est horrible, je conseil plutot de prendre un dico ^^

[crazyfred29 0]

Je confirme, mais si il devais tout retraduire au dico il aurai au moins pour une semaine complète le pauvre ^^.

Il faut dire que google traduction est pas terrible, j'en sais quelque chose j'ai du m'en servir pendant quelque mois, les phrase que je traduisais n'avais aucun sens j'ai du repasser derrière.

[Butcher44 0]

Lol oui désoler je sais que c'est pas top ce que raconte google mais on comprend quand même...

De toute façon je devrais faire sa au dico, j'aurais fini quand quand BF BC2 fonctionnera correctement... et encore pas sur.

Si non bien j'ai jouer tantôt, pas de problème de compte mais bon... rien na changer pour le moment.

Wait and see

[jakrenegade 0]

Je sais pas si c'est une consequence du reboot, mais mes connection au serveurs sont beaucoup plus rapide

[Kraken 22]

Visiblement il y aura une nouvelle maintenance prochainement, pas de date ni d'heure pour l'instant mais ca completera le boulot effectué hier et résoudra l'ensemble des soucis encore actuels .

http://forums.electronicarts.co.uk/battlefield-bad-company-2-ng/1387933-joe-grant-someone-dice-please-read-thread.html

*************

Message de zh1nt0 (DICE)

To complete the maintenance we need to do an additional downtime since this was only half of it. We are currently discussing internally when we can schedule this maintenance seeing as we want to go forward with this as soon as possible.

The real performance/matchmaking/connection and stats issues will be resolved once we have done that maintenance as well.

****************

Pour completer la maintenance nous avons besoin de faire un arret supplementaire.Nous sommes actuellement en train de discuter en interne pour planifier cette maintenance le plus vite possible.

Tous les problèmes de performance/Matchmaking/Connection seront résolus une fois que ce sera fait.

[Slydredd 0]

Bonjour, je suis nouveau sur votre forum et ma première question va peut être bête et mal placée.

Depuis hier, je ne peux plus me connecter à mon compte BF2BC2.

Je le message suivant : "connection impossible : réessayez".

Suis je le seul?

Est ce que c'est du au reboot qu'ils sont en train de faire, et tout reviendra en ordre quand ils auront finis?

Ou faut il que je cherche ailleurs une solution à mon problème?

Merci d'avance.

[Kraken 22]

Normalement c'est le reboot !

[Slydredd 0]

Ok, merci, je m'inquiètes pas alors, et je patiente... Mais pas cool de pas avoir sa dose de BF.

[RAZiEL 16]

donc nous sommes le 29/01 au soir et il y a toujours des soucis de stats ...

[Kraken 22]

donc nous sommes le 29/01 au soir et il y a toujours des soucis de stats ...

Je vient de faire une session journalière de 13h à 17h et de 21h45 à 03h20 et tout était nickel

[crazyfred29 0]

Hier j'y est jouer aussi aucun problème à déclaré même si j'ai eu du mal à trouver une place de libre sur un serveur, c'est le week-end faut s'y faire.