Corriger le lag : Et, pour ma part, je souhaite la bienvenue à nos nouveaux maitres des automates

Durant les tous derniers mois j'ai travaillé sur quelque chose de très cool dont certains d'entre vous ont pu entendre parler; c'est un projet pour refaire les entrailles du client EVE en lui enlevant les aspects audio et visuels du jeu. En d'autres termes, pour réduire le client autant que possible afin qu'il puisse être considéré "light" ou "allégé".

Et donc le Client Allégé (Thin Client) (TM) était né !


Que peut faire ce client allégé ?

La base pour ce client allégé est le client EVE que vous utilisez vous-mêmes; il en garde le coeur et étend et remplace certaines parties, afin de ne plus avoir besoin de carte son (insérez un commentaire générique "EVE a du son ?") ou de carte graphique pour le faire tourner.

En quoi ça me concerne ?

Le client allégé nécessite moins de ressources systèmes que le client traditionnel 100% matière grasse. Donc nous pouvons en faire fonctionner plus en parallèle sur un ordinateur. Là où un joueur (normal ?) d'EVE peut faire tourner 2 voire 3 clients simultanément avec un client traditionnel, il est possible d'en faire fonctionner de nombreuses fois ce nombre avec les clients allégés.

Le bénéfice évident d'un tel client est celui de l'échelle : vous pouvez lancer plusieurs centaines de ces clients et leur faire faire quelque chose, n'importe quoi.

Il devient possible de les régler afin de pouvoir entreprendre un test contrôlé à grande échelle; vous pouvez soumettre un changement du code et le retester avec le même réglage pour voir l'effet de ce changement. Le niveau de contrôle et de précision que ces tests nous donnent maintenant est sans précédent.

De telles pratiques ont été utilisées depuis longtemps pour tester la charge sur des sites web, en envoyant des requêtes aux sites à de nombreuses reprises pour découvrir les goulots d'étranglement du système. Cependant, pour EVE ce qui s'en approchait le plus ce sont les tests en masse sur Singularity que CCP Tanis organise.

Les tests en masses nous fournissent des données précieuses, mais ils peuvent être très difficiles à contrôler, puisque vous devez gérer entre 200 et 500 joueurs d'EVE vivants. Les clients allégés d'un autre côté sont des automates sans cervelle (NdT : je ne vois pas bien la différence avec certains joueurs), si nous leur disons de sauter d'une falaise, ils vont, métaphoriquement, aller directement au bord.

Ok, mais qu'est ce que ça signifie vraiment pour moi ?

Le client allégé en lui-même n'est pas plus intelligent que le client normal. Si vous lancez un client EVE normal, il ne se met pas soudainement à vouloir conquérir le monde à la Skynet (j'espère), et c'est pareil pour le client allégé. Pour surmonter cette différence nous avons créé plusieurs méthodes par lesquelles nous pouvons dire aux clients quoi faire. Les 2 méthodes sont des projets internes appelés Orchestrator et The Automaton Project, dont je vous reparlerai plus bas.

Pour pouvoir dire à un client quoi faire, nous avons créé pour nous-mêmes une énorme boite à outils qui peut être utilisé avec un grand bénéfice. Permettez-moi de donner quelques détails :

1. Il devient possible d'examiner le comportement d'un nombre massif de missions dans le même système. Pour examiner ce qui était l'effet Rens.
2. Nous pouvons systématiquement examiner le comportement de clients quand ils combattent dans des combats de flotte à grande échelle, ce qui nous permet de recréer et de diagnostiquer en labo les problèmes uniques que les grands combats de flotte créent.
3. Nous pouvons placer Jita sous un microscope afin que l'impact de plusieurs milliers de transactions sur le marché puisse être compris en détails.
4. Nous pouvons examiner juste quand une flotte jumpe sur une autre, l'écran noir de mort imminente apparait, et ce avec des étapes de reproduction plus complexes que le simple "prenez une grosse flotte et jumpez sur une autre".
5. Nous pouvons déterminer non seulement le seuil théorique mais aussi le seuil des performances réelles pour les systèmes complètement chargés, que les pilotes soient inactifs dans l'espace, chassent des NPC, fassent des courses, soient AFK, n'importe quoi.
6. Et finalement, nous pouvons évaluer l'impact à grande échelle des nouvelles mécaniques de gameplay. Les joueurs les plus anciens se souviendront des nombreux changements de gameplay au cours des années, attribués à l'amélioration des performances du serveur, comme la réduction du nombre de drones de 10 à 5 ou les changements sur la cadence de tir et les multiplicateurs de dégâts des armes pour limiter l'impact des armes à grandes cadences de tir sur le serveur, pour ne citer que 2 exemples évidents.

Cette nouvelle boite à outils nous permet de tester à la charge et au stress certains des composants les plus anciens et les plus complexes du jeu.

Assez de blabla, donnez-moi des trucs juteux ...

C'est là que je deviens technique, alors si le langage techo-geeko-nerd vous effraie, passez cette partie.

La question évidente est comment avons-nous réussi ça ? Le coeur de la solution passe par l'application de deux choses simples :

• Le mocking et les objets mock
• L'héritage des classes Python

Pour ceux d'entre vous sans connaissances en programmation, je vais clarifier : Le mocking est une méthode pour remplacer un objet par un autre qui est presque identique mais permet bien plus de contrôle. C'est un processus qui est utilisé pour tester des unités et permet au développeur de tester un morceau de code isolé. L'utilisation du mocking nous permet de remplacer les morceaux du code traditionnel qui s'appuient sur l'interface par des objets mock qui ne font rien. Si vous voulez en savoir plus, Wikipedia a une bonne page sur le sujet (lien fr).

La seconde étape a été l'utilisation de l'héritage standard du Python pour nous permettre de prendre le contrôle sur des morceaux particuliers du code; voici un exemple simple qui expliquera ça :

Considérez le système de ciblage : quand vous lancez un ciblage sur un vaisseau, un astéroïde ou autre chose, vous dites au serveur de locker la cible et de vous faire savoir quand c'est réussi, ou non, si ils sont trop loin.

C'est représenté sur votre client avec une nouvelle cible qui apparait en haut de votre écran. Avec le client allégé, vous n'avez pas d'interface et donc quand le client reçoit le message du serveur et essaye de charger l'icone, ça peut partir en sucette et déclencher des erreurs à propos de composants manquants pour l'interface et ainsi de suite.

En faisant un héritage de la classe qui gère le ciblage, nous pouvons remplacer la fonction qui cause l'erreur avec quelque chose qui gère proprement ce nouveau type de circonstances.

Bien sur, ça peut nous être très bénéfique. Ça nous permet de mettre en lumière les zones du code qui sont mures pour un refactoring, là où la logique de jeu et l'interface sont trop proches l'une de l'autre.

Dans beaucoup de ces cas, nous examinons et nous touchons un code ancien et nous touchons des bénéfices auxiliaires pour avoir revu ces fichiers avec un oeil neuf.

Et alors quelles sont les performances ?

Le client allégé moyen a une occupation mémoire d'environ 150 à 200 Mo. Pour tout le monde ce n'est pas forcément à ranger dans la catégorie "allégé", mais c'est un très bon début. En progressant il y aura d'autres manières de pouvoir réduire encore plus cette occupation. Pour ce qui est du CPU, le client en utilise très peu; presque tout le CPU est utilisé durant les 30 premières secondes, quand toutes les bibliothèques Python et le code sont chargés en mémoire. Une fois que c'est terminé le client revient relativement discret. Malheureusement, quand vous en faites tourner plusieurs centaines en même temps, même des fluctuations mineures sur le CPU, qui ont lieu sur tous les clients en même temps, peuvent poser des problèmes, donc c'est quelque chose que nous tenons à garder au minimum.

Mais le contrôle ? Comment vous leur dites quoi faire ?

L'Orchestrator est le cadre que nous avons développé pour faire fonctionner nos systèmes de test. Sa fonction principale est de paramétrer un serveur et un client et d'effectuer un test particulier sur le client avec des mécanismes traditionnels de réussite / échec.

Le seul problème avec ce scénario c'est qu'Orchestrator est un système très possessif; il veut avoir le contrôle total de tout, les proxies, le serveur et les clients qui se connectent, et pour ce que nous faisons il se montre un peu trop avide. A cause de l'architecture d'Orchestrator, ce n'est pas le candidat idéal pour un contrôle à grande échelle de clients, mais il nous permet de faire des tests ciblés en utilisant moins de clients esclaves.

Pour ce qui est de l'Automaton Project ("Projet Automate"), bon, il faut que je l'avoue, il n'y a que moi qui l'appelle comme ça, c'est le nom que je préfère. Ce projet est un moyen de rendre autonome le client pour qu'il exécute localement un code arbitraire, plutôt que d'avoir ses mouvements dictés par un contrôleur situé ailleurs sur le réseau.

La différence entre les deux méthodologies que nous avons pour contrôler les clients, c'est que l'une repose sur un paradigme maitre / esclave, tandis que l'autre est un groupe d'acteurs totalement autonomes; chaque solution a ses avantages et ses inconvénients et nous ne voulons pas suivre aveuglément une voie particulière juste pour nous rendre compte qu'elle est en fait la cause de nos problèmes plutôt que la solution.

Et alors quand est-ce que je pourrai avoir ça ?

Jamais, désolé :). Ce client est un outil pour développeur uniquement et bien que beaucoup de monde désire un client qui demande moins de ressources, ce n'est pas le client que vous recherchez </jedi>

Et maintenant ?

Maintenant que nous avons ces outils, il nous reste du travail à faire pour créer des tests pour eux. CCP Veritas s'est amusé avec eux récemment et a découvert quelques pointeurs intéressants en chassant l'infâme monstre du lag, mais je suis sur qu'il détaillera ça dans son propre blog.

Quant à moi, il y a beaucoup plus d'API qu'il faut coder pour permettre au client d'en faire plus. Notre but principal est de résoudre le problème du lag, mais au delà de ça je veux créer une interface de marché qui nous permettra de régler du commerce de masse afin de pouvoir émuler Jita. Il faut aussi transformer une horde (un troupeau ? Comment vous appelez un groupe de ces trucs ? Une armée ?) d'automates asynchrones en une flotte organisée, puis il reste du travail à faire pour l'alléger encore plus, etc etc, ad infinitum.

Il y a une chose sur laquelle je veux insister cependant : nous avons toujours besoin de votre aide. Une fois que nous aurons utilisé ces clients et d'autres outils pour trouver les problèmes et les corriger, nous aurons besoin de chacun d'entre vous, de votre temps et de vos efforts pour vérifier ces correctifs sur Singularity. Les joueurs d'EVE ont une inventivité énorme, et nous avons besoin de ça et de votre résilience pour nous aider à tester ces correctifs en situation de stress.

Et sur cette note, au revoir !

Par CCP Atropos
Traduction : Ineeh
Source