Initiation à Gatling, un outil de tests de charges

Après avoir développé, testé fonctionnellement une application, une autre étape importante consiste à tester l’application dans des conditions plus proches de la production. Pour cela, une étape de tests de charge semble indispensable. En effet, une application est souvent testée unitairement par un développeur, profil après profil, fonctionnalité après fonctionnalité.

Nous allons nous intéresser ici à un outil permettant de réaliser ces tests de charge, à savoir Gatling. Gatling est un outil basé sur le langage Scala, Netty et Akka. Grâce à Netty, les requêtes sont lancées de manière asynchrone, ce qui permet d’utiliser un grand nombre d’utilisateurs virtuels. Les scénarios générés sont écrits en langage Scala. Ce langage est proche de Java mais est plus simple à appréhender. Quant à Akka, c’est un Framework qui implémente le modèle d’acteurs.

Gatling s’installe facilement grâce à un fichier zip. Étant basé sur Akka, il a néanmoins besoin de la présence du JDK pour fonctionner. Il suffit ensuite de paramétrer manuellement son navigateur pour qu’il passe par le port 8000.

Création du scénario

Les scénarios peuvent être écrits entièrement à la main, ou nous pouvons utiliser le « recorder ». Celui-ci permet d’enregistrer un scénario simplement en navigant dans l’application, à la façon d’un internaute. Le scénario généré peut ensuite être modifié à l’envi à l’aide du langage Scala.

Nous allons ici tester Gatling dans sa version la plus simple. Prenons par exemple une application de réservation de billets de train :

• Ouvrir l’URL du site
• Rechercher un billet aller-retour Paris-Marseille pour une personne avec une carte jeune de réduction
• Accéder à l’ensemble des tickets disponibles
• Choisir le trajet aller et valider
• Choisir le trajet retour et valider
• Renseigner les données pour le mail récapitulatif
• Accéder à la page de paiement

L’entête du fichier est généré automatiquement, suivant les informations renseignées dans la fenêtre de Gatling. Par défaut, le nom de la classe est « RecordedSimulation ». Le nom du package doit commencer par une lettre est doit être en minuscule.

Le fichier résultant va être créé dans le répertoire paramétré dans « Output folder » et, dans notre exemple, va porter le nom « RecordedSimulation.scala ».

Dans l’entête du fichier généré se retrouve le nom du package et du nom de la classe. De plus, la variable baseURL indique l’adresse principale du site testé. Les fichiers générés peuvent être modifiés grâce à un éditeur de texte type Notepad++. Ils peuvent également être ouverts dans Eclipse, si celui-ci est présent sur le poste.

Lorsque l’on navigue sur une page web ou que l’on saisit des informations dans un formulaire, toutes les URLs sont enregistrées par Gatling. Un extrait des actions exécutées lors de la saisie des villes de départ et de destination est présenté, ici un Paris-Marseille aller-retour. Plusieurs fonctions similaires sont générées car la fonction d’autocomplétion est enregistrée.

Ce type d’enregistrement génère un grand nombre de requêtes. Nous pouvons modifier leur nom, afin de les rendre plus parlantes. Cela permettra de les retrouver plus facilement dans les graphiques de résultats. Nous allons détailler la saisie des informations après validation des billets aller et retour et avant la page de paiement. Le site demande la date de naissance du voyageur, ses nom et prénom ainsi que son adresse email.

Le nom de la requête a été ainsi modifié :

Ce morceau de scénario peut être écrit comme une fonction. Ceci permet de factoriser le code et de potentiellement le réutiliser par la suite.

La génération des scénarios est donc facilitée par l’utilisation des fonctions. Un scénario se compose d’une succession de fonctions. Une même fonction pouvant être appelée par plusieurs scénarios, il est donc possible de lancer plusieurs fois les mêmes actions, par exemple pour des profils différents.

Pour l’instant, le scénario est exécuté par une seule personne avec des informations de date de naissance, de nom, de prénom et d’adresse email fixes. Nous pouvons pousser le paramétrage de la fonction de saisie d’information avec un fichier. Dans notre exemple, nous pouvons mettre en facteur le jour, le mois et l’année de naissance, les nom et prénom ainsi que l’adresse email.
Le fichier nécessaire à ce paramétrage doit être un fichier au format CSV. Le nom des colonnes doit reprendre le nom des variables qui sera utilisé par la suite dans le scénario. Un exemple de fichier est présenté ci-dessous. Notre fichier se nomme param.csv.

Le nom du fichier paramétré doit être inséré dans la fonction où il est appelé, avant l’appel des variables. Les variables ainsi définies sont appelées grâce à l’écriture ${nomvariable}, ce qui donne un fichier plus générique.

Paramétrage du test de charge

Pour l’instant, un seul utilisateur se connecte à l’application. Pour faire des tests de charge probants et simuler les vraies conditions de navigation, le nombre d’utilisateurs peut être augmenté. Par exemple, 6 utilisateurs peuvent se connecter à l’application toutes les 15 secondes grâce aux fonctions inject et rampUsers.

Si nous voulons plutôt tester des utilisateurs simultanés, il faut utiliser la fonction atOnceUsers avec le nombre d’utilisateurs en paramètre. Par défaut, le scénario est enregistré avec un seul utilisateur.

Affichage des résultats

Les résultats sont ensuite disponibles, après leur génération dans un répertoire /results. Un nouveau dossier est généré, portant le nom de package, suivi d’un tiret et de plusieurs chiffres. Les résultats sont fournis au format HTML et la page racine, index.html, permet d’accéder à l’ensemble de ces derniers.

Un premier graphique en bâtons fournit une vue du temps de réponse des requêtes. Les requêtes sont partagées en différentes catégories suivant leur temps de réponse. Dans notre cas avec un utilisateur, nous pouvons voir que plus de 400 requêtes répondent en moins de 800 ms, mais qu’un certain nombre sont en erreur, dans la colonne ‘failed’.

Dans ce deuxième graphe en bâtons, où 10 utilisateurs sont envoyés en simultané, il est possible de voir que le résultat est plus nuancé. On peut noter que l’écrasante majorité des requêtes répondent en moins de 800 ms à quelques exceptions près. On retrouve également des requêtes en erreur.

La page index.html contient également un tableau récapitulatif de toutes les requêtes. Pour chaque ligne, on peut voir le nombre de requêtes total, le nombre de requêtes OK, le nombre de requêtes KO ainsi que les temps de réponses.

En cliquant sur le nom d’une requête, une nouvelle page s’ouvre, pour afficher les résultats de la requête spécifiquement. Par exemple, si on ouvre la request_41, il est possible de voir que 7 requêtes ont abouti en moins de 800 ms et 3 n’ont pas abouti.

D’autres types de graphiques sont également disponibles. Par exemple, nous pouvons voir le nombre de requêtes par utilisateur ou le nombre de réponses par utilisateur.

Ces analyses permettent de voir quelles requêtes sont les plus problématiques, et de corriger le tir rapidement.

Synthèse

Gatling dispose de nombreux points forts :

• Cet outil est gratuit et simple à installer. Il ne requiert aucun logiciel supplémentaire hormis un JDK à jour.
• La facilité d’utilisation du recorder : avec un simple navigateur et un minimum de paramétrage, il est possible d’instancier de nombreux scénarios, des plus simples au plus complexes.
• L’existence d’un plug-in pour Eclipse : pour les développeurs Java, il devient simple de lancer le recorder, ou par la suite de lancer les tests de charge.
• La possibilité de créer des scénarios ou de les modifier grâce au langage Scala. Le langage Scala est suffisamment simple et « parlant » pour pouvoir être utilisé facilement.
• La clarté du site : La documentation sur le site est assez complète pour faire des scénarios simples, puis pour les complexifier par la suite.
• La détection des problèmes de compilation : lorsque nous essayons de lancer les tests de charges, l’outil pointe les erreurs de compilation dans la console.
• La clarté des graphiques générés : nous pouvons faire aisément des analyses globales ou des analyses plus détaillées, requête par requête.

Gatling a aussi ses points faibles :

• La génération différée des rapports : les rapports sont générés après l’exécution de la totalité des tests de charge.
• L’interface qui permet de lancer les tests de charge, dans sa version native, n’est pas graphique.

En conclusion, Gatling gagne à être connu et utilisé dans le cycle de vie d’un projet. Avec un minimum de connaissance en langage informatique, des scénarios complexes peuvent être élaborés. Cela permet de pointer du doigt les portions d’application à modifier ou à optimiser. Je l’ai testé dans sa version la plus basique. Malgré un manque d’ergonomie dans l’outil de tests de charges en lui-même, les fichiers générés se retrouvent facilement et le paramétrage est aisé.