Découvrez Gatling, un outil de tests de charge écrit en Scala, qui mitraille littéralement votre application. Stéphane Landelle est directeur technique chez eBusiness Information, du groupe Excylis. Il est le responsable technique et développe activement sur le projet. Romain Sertelon est le développeur principal de Gatling. Il a effectué son stage de fin d’études chez eBusiness Information avec pour sujet Gatling. Aujourd’hui, ils nous présentent l’outil et son fonctionnement.
Gatling is a web performance testing tool written in Scala, that relies on Akka, Jboss Netty and Async Http Client to litteraly explode your web application and ensure that it works under heavy stress-load. The project is hosted on Github : https://github.com/excilys/gatling
Gatling en quelques mots
Gatling est un outil opens-source lancé en décembre 2011. C’est un outil de stress qui permet de tester la montée en charge d’un site Internet. Il simule un grand nombre de connexion sur le serveur, en jouant des scénarii pré-enregistrés. Les résultats sont ensuite analysés à posteriori, pour fournir différentes courbes et indicateurs.
Gatling est donc une alternative à JMeter, en exploitant un moteur en Scala à base d’Actors, et en utilisant le principe des entrées/sorties non bloquantes. Il s’appuie sur Akka, sur Async Http Client de JF.Arcand et enfin sur JBoss Netty.
Pourquoi les tests de charge sont importants ?
Pourquoi le test en charge est-il important ? Réaliser des tests de charge est important. Cela devrait faire partie du cycle de développement. Stéphane explique qu’il a enchainé différentes missions, et qu’il a testé les outils du marché : Apache JMeter, Grinder, OpenSTA ou encore HP LoadRunner… difficile de trouver la solution qui l’intéressait. Surtout, particulièrement pour JMeter, son expérience montre que l’outil n’est pas adapté à de très gros tests de charge. Romain explique que JMeter ne dépasse pas les 1514 injecteurs sur une seule machine.
Par ailleurs, Stéphane voyant ce que Scala propose, trouve qu’il y a un sujet intéressant à lancer, et le projet démarre donc en juin dernier avec Romain.
Principes importants
Gatling est une solution asynchrone. En général, les solutions classiques utilisent l’approche « 1 virtualUser=1 thread ». Cette approche est limitée dès lors qu’il s’agit de vraiment « taper » dans le serveur. Cela fonctionne, mais l’injecteur est pénalisé par de nombreux context-switching.
Ensuite, l’asynchrone coule de source si l’on réfléchit quelques instants à ce que font vraiment les visiteurs d’un site Internet. Vous par exemple, vous êtes entrain de lire cet article, un café à la main, l’oeil encore un peu fatigué de votre week-end. Et pendant ce temps-là, le serveur ne fait rien. C’est ce que l’on appelle le « Think-Time ». L’idée de Gatling est d’utiliser ce temps de pause dans votre scénario pour faire exécuter une tâche à un autre virtual-user. Simple non ?
Au lieu de mettre une thread en sleep, ce qui coûte des ressources, Gatling a une Thread d’exécution qui enchaine les traitements. Au final, Stéphane explique que le moteur tourne avec de 30 à 40 threads grand maximum pour environ 12500 Virtual User sur une machine classique, type Intel 4-Core i7. Je testerai cela et je vous donnerai mes résultats.
Les scénarii sont du code
Gatling c’est une arme pour les développeurs. Plutôt des personnes capables de coder. La puissance de Scala et la facilité pour écrire une belle API, permettent à Gatling d’avoir un moteur de scénario très puissant et très simple. Vous pouvez soit écrire un scénario directement sous la forme de code Scala, soit importer un scénario écrit avec du Scala, mais en utilisant l’API.
J’ai travaillé avec de vrais ingénieurs QA, qui savent coder, et je pense qu’il n’y aurait pas de difficultés à leur faire utiliser l’outil. C’est même moins verbeux qu’un scénario OpenSTA.
Ensuite, une idée intéressante, c’est le typage fort et la vérification du scénario à la compilation. Oui, votre scénario est compilé, et donc il est validé avant de l’envoyer sur vos injecteurs. Pas d’interprétation à la volée, qui d’après Stéphane, est trop gourmand en ressources. Avoir un scénario « type-safe » en quelques sortes.
Des rapports sympas
Gatling ne fait pas de reporting en temps réel pour l’instant. L’outil effectue son tir, peut s’appuyer sur une base JDBC en entrée pour charger des données, mais les rapports sont générés à posteriori. L’ensemble est sympa, avec des librairies de Chart en Javascript.
A titre personnel, pour le projet CMesDonnées.com, j’ai utilisé HighCharts. Simple et facile à mettre en place, il fait de très belles courbes à votre projet. Pardon, il donne de belles courbes à vos données.
Les différents composants de l’outil
Gatling est hébergé sur GitHub. Vous pouvez télécharger une version stable dans la section Downloads. Après avoir installé l’outil, vous avez :
– un Recorder, client Swing qui démarre un proxy http pour enregistrer les requêtes.
– un outil de reporting pour analyser les résultats et générer des pages webs de rapport
– le moteur d’injection, qui prend un scénario et qui l’exécute
Il y a aussi déjà un artefact Maven pour faciliter la création d’un projet Gatling.
Techniquement, Stéphane entre ensuite dans les détails de l’outil. J’ai retenu que pour le parsing XML, le plus efficace est VTD-XML. La documentation complète de Gatling est en ligne sur le Wiki.
Pourquoi Scala ?
La motivation au départ était d’utiliser Akka. Ce moteur d’Actor très puissant et très simple à utiliser, permet de découper l’exécution des étapes d’un scénario. Il y a aussi pas mal de stratégie pour gérer les itérations et le branchement conditionnel, d’un Actor à l’autre. La présentation est allée assez loin dans les détails, on retiendra que le principe d’Actor est un outil excellent pour développer une application avec des éléments asynchrones.
Nous avons eu ensuite plusieurs démonstrations de l’outil, pas mal de discussions intéressantes sur l’implémentation et les choix techniques. L’outil est encore jeune mais il fonctionne bien. Vous pouvez le tester et donner votre avis à Stéphane et à Romain.
Pour terminer :
– télécharger Gatling
– le wiki
Petite faute à corriger « JMeter ne dépasse pas les 1514 injecteurs sur une seule machine. »
C’est pas des injecteurs mais des VU (Virtual User)
« Pourquoi les tests de charge sont importants ?
Pourquoi le test en charge est-il important ? Réaliser des tests de charge est important. Cela devrait faire partie du cycle de développement. »
Cela fait un peu bourrage de crâne. L’intérêt des tests de charge se montre par leur retour sur investissement. Nous sommes d’accord qu’en avoir n’est pas une mauvaise chose. Mais dans le cas de la réalisation d’une application interne, pour une grande entreprise, avec une plateforme standardisée et devant servir à un petit nombre de personnes, cela n’est pas nécessairement pertinent.
Par contre, si jamais les performances sont un aspect critique pour l’application alors l’architecture et la stack logicielle doivent être pensées dans ce sens. Dans ce cas la, effectivement, les tests de charge sont nécessaires pour valider la solution choisie.
Et Gatling a l’air d’être un outil intéressant pour cela.
Je confirmes, JMeter et compagnie sont beaucoup trop limités pour faire de véritables test de charges.
Perso je n’utilise plus que Tsung y compris dans jenkins. Faut avoué qu’avoir des tests de charges directement lancés dans la chaine d’intégration continue c’est supper efficace.