Utilisation de gatling

Je ne présente pas gatling. Je pense que tout le monde a dû entendre parler de près ou de loin de cet outil permettant de tester la montée en charge d’une application web en implémentant des scénarii, le nombre d’utilisateurs à la seconde, etc.

Ce qui va nous intéresser ici est l’implémentation d’une solution simple.

La première chose à faire est de créer un répertoire gatling (pour l’exemple, je l’ai fait à la racine de l’arborescence d’un projet Symfony2). Il comportera quatre répertoires: properties, resources results et scala.

  • properties va comporter un fichier de propriétés selon les différents environnements sur lesquels vous souhaiter tester votre site: local, preprod, prod
  • resources est ici mis à titre indicatif. Il comportera deux répertoires, conf et data. Je ne me sers de conf que lorsque je créé un container docker et que je souhaite pouvoir surcharger la conf gatling à l’intérieur du container. Data comportera des fichiers csv, par exemple, pour nourrir vos scénarii.
  • results comportera les fichiers html de résultats des tests de montée en charge.
  • scala est le répertoire le plus intéressant car il comporte les fichiers de scénarii.

Le fichier properties/test-parameters.properties

Le fichier scala/Config.scala

Il va nous permettre d’interroger le fichier test-parameters.properties pour en récupérer les informations renseignées:

Rien de compliqué:

  1. J’ouvre le fichier test-parameters.properties et je lance une erreur si je ne le trouve pas ou qu’il n’est pas lisible:
2.   Je récupère la plateforme (preprod ou prod) et le host correspondant:
3.    Je définis une fonction, get, qui va rechercher la propertyName (exemple home.prod.minResponseTime), puis sa value correspondante et la retourner
4.    Je définis une seconde fonction, getInt, qui va transformer en integer la value retournée par la fonction get()
5.    Enfin, je définis une série de fonctions qui vont appeler getInt, en fonction de la propriété recherchée
6.     Enfin, je définis deux fonctions (la seconde appelant la première), usersPerSecond et testLabel afin de retourner, à chaque test, un texte en rapport avec le nombre d’utilisateurs par seconde

Le fichier scala/performance/home.scala

Il est temps d’écrire notre premier scénario simple qui va interroger une url et nous en sortir des statistiques:

  • Je définis le testName (utilisé dans Config)
  • Je définis la config avec un new jpsymfony.config(testName)
  • Je fais appel à la librairie Calendar pour créer un timestamp qui changera à chaque appel (pour que varnish ne me retourne pas la réponse en cache dès le second appel)
  • le host est défini (ici platform.prod.host, soit www.jpsymfony.com
  • Je crée le scénario en faisant appel à config.testLabel pour que le texte affiché soit conforme avec le nombre d’utilisateurs qui rentrent par seconde
  • Je demande à injecter les utilisateurs sur un nombre de secondes définis dans le fichier test-parameters.properties (plutôt que tous d’un coup) et je vérifie un certain nombre d’assertions (qui, pour récupérer les valeurs, font toutes appel aux fonctions définies dans le fichier Config.scala)

Juste avant de lancer le test, je tiens à vous montrer ce que vous pouvez faire si vous placez des csv dans le répertoire data, avec par exemple l’entête id (donc une seule colonne ayant une entête id, par exemple:

id
1
2
3
Et pour le test, il faut changer la fin:
C’est parti pour lancer le test!

Je présume que vous avez installé gatling en suivant la doc du site. Nous allons donc lancer la commande en nous plaçant dans le répertoire gatling:

sudo /opt/gatling/bin/gatling.sh -rf results -sf scala/

-rf indique où les résultats doivent se placer, et -sf où les scénarii se trouvent:

Il n’y a plus qu’à se rendre sur la page html pour voir les résultats à l’endroit indiqué:

gatling

gatling2

Avant de nous quitter, pour les habitués à docker, voici ma configuration:

Ici, deux répertoires ont été rajoutés: scripts et bodies. bodies est utilisé lorsqu’on détermine des bodies json, par exemple.

Ce body peut être utilisé lors d’un post (il faut bien sûr avoir un feeder pour que ${token} et {id} soient renseignés:

 

Le répertoire scripts contient un script non_reg.sh qui me permet de lancer tous les tests d’un container:

Ainsi, je n’ai plus qu’à créer un alias pour exécuter tous les tests:
alias gatling_non_reg='docker exec -t jpsymfony-gatling /scripts/non_reg.sh'

Je peux aussi créer un alias pour que l’on me propose de choisir le test à exécuter:
alias gatling_test='docker exec -it jpsymfony-gatling /opt/gatling/bin/gatling.sh -rf /opt/gatling/results/'

Je peux alors lancer la commande  gatling_test -s jpsymfony.performance.Home  pour lancer un test en particulier ou  gatling_test  pour que l’on me demande quel test exécuter.

Rédigé par

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *