Gatling injecteur de tests de charge

Gatling est un projet Open Source permettant de faciliter la création et l’injection de scénarios de tests dans une application. Il a été créé en 2011 par Stéphane Landelle. Je vais dans cet article, revenir sur l’intervention de Stéphane au LyonJug le mardi 17 octobre 2013.

Pour commencer il est intéressant de noter que Stéphane Landelle fait partie de la société ebusinessInformation du groupe Excilys. Cette société participe à plusieurs projets Open Source comme Gatling évidemment mais aussi 

• AndroidKickStartR (que j’avais présenter dans un article) permettant de générer un squelette de projet 
• AndroidAnnotation facilitant l’écriture des applications Android qui avait été aussi présenter au LyonJug en 2012

Les tests de charge
Souvent jugés trop chers et trop complexes par rapport à l’intérêt apporté, les tests de charge sont très souvent oubliés dans les entreprises. Sauf que les conséquences peuvent être importantes voir désastreuses. Cet article parle des coûts que peuvent entraîner des coupures de service en production.

Les tests de charge permettent de valider la robustesse d’une infrastructure, d’une application en fonction du nombre d’utilisateurs attendu. Aujourd’hui avec la tarification des services cloud en fonction des ressources utilisées, il y a un réel intérêt de ne pas négliger cet aspect performance si vous voulez maîtriser vos coûts d’hébergement.

La notion de performance est assez vague et on peut aussi bien parler de rapidité, de robustesse, de consommation de ressources… Il est important de définir son besoin avant de commencer une campagne de tests. On peut se baser sur les performances d’une application déjà en production dans le cadre d’une migration, des objectifs de vente définis par les clients… Il faut cependant garder à l’esprit que le ressenti des performances est très subjectif et contextuel et dépendra des personnes et du métier des utilisateurs.

Comment tester ?
Tester les performances nécéssite plusieurs outils pour

• injecter des scénarios de tests : il existe plusieurs injecteurs Gatling, The Grinder, Load Runner, Jmeter, Tsung... 
• monitorer ce qu’il se passe au niveau système, au niveau réseau, au niveau base de données 
• faire du reporting

HP Load Runner qui est considé comme la F1 du test de charge offre une solution complète mais il est hors de prix. Mixer les petits outils est la solution la plus courante

Les tests de charge vont permettre d’identifier les goulets d’étranglement. Mais pour que vos tests soient pertinents ils doivent être en accord avec une vraie utilisation. Il faut multiplier les données en entrée car dans le cas contraire vous ne testerez que des données qui sont présentes dans votre cache si vous en avez mis un en place. Dans le cas d’une application qui tourne sur une JVM, exécuter x fois le même scénario fait que le JIT peut faire des optimisations que l’on ne retrouvera pas dans un contexte d’utilisation normal.


Il existe plusieurs types de tests de performances en fonction de ce que vous voulez vérifier

• des tests de charge pour vérifier que les utilisateurs simultanés prévus peuvent bien se connecter et utiliser l’application en même temps 
• des tests de stress afin de vérifier que l’application est capable d’encaisser des pics de charge tout en revenant à un état stable après 
• des tests d’endurance pour vérifier qu’il n’y a pas de fuites mémoire dans le temps 
• des tests au limite pour connaître jusqu’où le système peut aller

Faire des tests de charge se fait en mode itératif

 

Pourquoi un nouvel outil ?
La liste des outils permettant de créer et exécuter des tests de charge sont nombreux. J’ai cité plus haut The Grinder, Load Runner, Jmeter, Tsung… Pourquoi développer une nouvelle solution ?


Stéphane Landelle nous a expliqué que l’idée de Gatling lui est venu après avoir utilisé plusieurs de ces outils et avoir constater plusieurs choses

• ils sont pour la plupart bâtis sur le postulat un utilisateur = un thread. Ceci pose des problèmes de performance et nécessite de monter des clusters d’injecteurs. 
• ils utilisent des io bloquants ce qui est particulièrement génant quand on implémente des temps de pause dans les scénarios car ceci implique de mettre en pause un thread.... Et la pause chez un thread c’est sacré il ne fait rien... 
• ces outils sont axés interface utilisateur. Les fichiers de données sont optimisés pour ces interfaces et non pas pour une lecture humaine. Quand on est développeur dans l’âme on préfère des outils proposant des API claires et riches à des interfaces graphiques gourmandes en ressources

Le problème au final, c’est que suivant l'outil on peut en venir à douter des performances de l’injecteur…. Pour s’en convaincre il suffit de regarder la page de Jmeter sur les performances. Même si les performances s'améliorent il y a beaucoup de variabilité induite par l'outil quand le nombre d'utilisateur augmente.
 
Comment fonctionne Gatling ?
Gatling est programmé en Scala sur un modèle à acteurs. La programmation orientée acteurs a été introduite dans un article de 1973 et a été utilisée par Ericson dans les années 80 pour concevoir ses systèmes téléphoniques. Aujourd’hui Akka propose un ensemble d’outils pour faciliter la création d’applications Java ou Scala basées sur des acteurs. Cet article sur le blog d’Octo introduit le concept.

Il faut retenir qu’un acteur est un composant autonome immuable qui reçoit des messages et en renvoie d’autres en mode asynchrone. Pour éviter des io bloquants, Gatling utilise le framework Netty. Cette architecture asynchrone permet à Gatling d’optimiser l’utilisation des processeurs. Au lieu de faire un sleep sur un thread, les traitements s’enchaînent sur un thread d’exécution. Ce modèle permet d'augmenter considérablement le nombre d’utilisateurs simulés sur la même machine.


Les scénarios sont écrits en scala en utilisant plusieurs DSL en fonction de ce que l’on veut faire

• scenario : décrivant les actions utilisateurs 
• feeder : injecteur de données dans votre scénario 
• scenario configuration 
• http action : pour définir les requête HTTP envoyées par le scénario 
• checks : pour vérifier les réponses 
• http configuration 
• assertions : pour contrôler qu’un résultat correspond aux attentes

Pour faciliter l’écriture des scénarios Gatling propose un Recorder permettant d’écouter les requêtes HTTP pour les transcrire en scénario écrits en Scala.

Il existe plusieurs outils facilitant l’utilisation de Gatling comme

• plugin maven 
• plugin jenkins 
• exemple de projet basé sur maven 
• Graphite live reporting 

Démonstration
Dans la dernière partie de son talk, Stéphane nous a fait une démo de l’utilisation de Gatling.

Exemple de scenario

class SimulationWithFollowRedirect extends Simulation { 
  // your code starts here
  val scn = scenario("My scenario")
            .exec(http("My Page")
              .get("http://mywebsite.com/page.html"))
  
  setUp(scn.users(10))
  // your code ends here
}

Recorder


Exemple de rapports


Et après ?
Gatling est toujours en cours d’évolution. La version 2 est en cours d’écriture (version milestone 2.0M3-a) et plusieurs fonctionnalités sont prévues pour la suite websocket, jdbc, clustering....

Je dois dire que cette présentation m’a donné envie d’essayer. Si ce test est concluant je ferai un retour dans un prochain article.

Merci Stéphane pour cette intervention

Voici quelques ressources supplémenataires : Le wiki gatling, un article sur Xebia