Gatling est un logiciel qui permet de tester la charge et les performances d’un site ou d’une application web.
Il inclut un outil de test de charge, un générateur de rapport au format HTML, et un enregistreur de simulation.
Gatling va lancer des simulations, qui vont contenir un ou plusieurs scénarios.
Ces scénarios sont composés de requêtes à exécuter.
Des utilisateurs fictifs sont ensuite injectés au scénario pour simuler une charge et/ou un timing donné (exemple : 10 utilisateurs pendant 30 secondes).
Pour établir ces simulations Gatling propose deux solutions :
- utiliser le recorder
- coder soi-même les classes en Scala
Utiliser le recorder
Gatling met à disposition un recorder (fichier bin/recorder.sh), qui une fois lancé va capturer les requêtes HTTP qui transitent.
Pour ça il faut configurer son navigateur, ou Postman (ou autre) en indiquant le détail du proxy proposé par le recorder (IP et port).
Une fois terminé, il va générer automatiquement une simulation : un fichier RecordedSimulation.scala
Coder sa simulation
Dans le cadre d’un test de performance d’API, il va surement être nécessaire de passer par le code plutôt que le recorder afin de réutiliser certaines données dans des variables (exemple : un token).
L’autre avantage est de pouvoir versionner son code et l’inclure dans une suite d’intégration continue.
Prenons l’exemple d’une plateforme qui héberge plusieurs API, comme Gravitee.
Dans un premier temps on va vouloir s’authentifier et garder le token en session, puis effectuer une batterie de requêtes sur les différentes API disponibles sur le portail (plateforme d’API Management).
On peut isoler les requêtes et scénarios dans des classes Scala séparées, et les grouper par API.
La classe de simulation (qui fait office de bootstrap) aura pour but d’exécuter tous les scénarios en y injectant les utilisateurs.
Ce billet explique comment mettre en oeuvre cette architecture.
Lancer les tests
Les test de performance se lance à l’aide du fichier bin/gatling.sh.
Sélectionner la simulation souhaitée et valider, l’outil va cracher du log en sortie (plus ou moins verbeux, paramétrable via le fichier conf/logback.xml).
Visionner le rapport
Le rapport au format HTML est généré dans le dossier result/simulation-name-date/
Il présente les données sous forme chiffrées et graphiques (histogramme, camembert), au global et au détail des requêtes.
Intégrer au CI/CD
A l’instar de JMeter, Behat (BDD), ou Wapiti (sécurité), il est possible d’intégrer automatiquement les tests de charge au job Jenkins ou autre outil d’intégration continue.
