Mise en place des tests de charge avec Gatling

 

# INTRODUCTION

         Dans certains projets à fort trafic, les tests de charge sont souvent négligés faute de temps ou bien faute d’outils simples à intégrer au projet. Et ceci à tort, car seuls les tests de charge permettent de valider correctement une application ou un système avant déploiement, tant en qualité de service qu’en consommation de ressources.

Les tests de performance doivent être implémentés et réalisés tout au long du cycle de développement, et ce le plus tôt possible. Un résultat plus ou moins précis maintenant vaut mieux qu’un résultat très précis plus tard.
[RAPPEL] Une application est généralement testée unitairement par un développeur, profil après profil, fonctionnalité après fonctionnalité. En effet, après avoir développé, testé fonctionnellement une application, une autre étape important consiste à tester l’application dans des conditions plus proches à la production. Pour cela, une étape de tests de charge semble indispensable :

 

  1. Analyse de Référence
    L’analyse préliminaire consiste en l’enregistrement d’un ou de plusieurs scénarios (ou cas d’utilisation) pour mieux comprendre l’application et l’entendue du test.
    Il est nécessaire de définir dans un premier temps le système à tester, les processus métier et les objectifs, par la suite les scénarios, par rapport à une analysé complète des risques métiers et techniques, le modèle de charge, par rapport au modèle d’usage de l’application, il faudra notamment caractériser les données pour chaque scénario et enregistrer les scénarios
  2. Test Préliminaires
    Mettre en œuvre des moyens et définir la plate-forme de test, exécuter les tests de charge (préliminaires) et analyser les résultats
  3. Test de Charge à Grande Échelle
    Mettre en œuvre des moyens et définir la plate-forme de test, exécuter les tests de charge, analyser les résultats et optimiser le système

 

# CONTEXTE

Le projet Gatling tire son nom et son logo de la première mitrailleuse efficace combinant fiabilité, puissance de feu et facilité d’alimentation. Le principe conçu et mis au point par Richard Gatling, en 1861, offre le moyen de paralléliser efficacement les opérations mécaniques nécessaires (chargement, percussion, extraction, éjection et laisse chambres et canons mieux refroidir donc atteint des cadences de tir élevées, sans commune mesure avec les armes à un seul canon.

Ceci étant dit, on peut faire le lien entre les analogies de cette mitrailleuse du 19eme siècle et le projet Gatling :

  • Fiabilité : développé en Scala et s’exécutant sur la JVM
  • Puissance de feu / Parallèlisation des opérations : client http asynchrone basé sur Netty (netty.io) et utilisation d’acteurs Akka (akka.io)

  • Facilité d’alimentation : un domaine de langage dédié (DSL) clair et concis

En plus de cela, Gatling utilise Highcharts (highcharts.com) pour générer ses graphes.

 

# INSTALLATION 

Il existe deux possibilités pour utiliser Gatling en tant qu’outil de test de montée en charge :

  • Télécharger l’outil sur https://gatling.io/download/) et dézipper l’archive dans un répertoire mettant à disposition deux scripts (bat ou shell selon votre OS) permettant de lancer l’outil d’enregistrement d’un scénario puis de démarrer le moteur d’exécution d’un test.
  • Intégrer la solution au sein de l’outil de développement Eclipse afin de disposer d’un projet « Gatling » permettant de manière plus confortable d’enregistrer, éditer (en bénéficiant notamment de la complétion) et exécuter les scripts de test

La première solution permet de déployer une solution de tir en quelques minutes alors que la seconde met à disposition un environnement de développement parfois nécessaire pour réaliser des scénarios de tests complexes.

 

# EXEMPLE

         Gatling est founi directement via une archive tout-en-un disponible sur https://gatling.io/download. La version utilisée ci-dessous sera la 2.3.0.

 

 

Pour les utilisateurs de Windows, il est recommandé de ne pas placer Gatling dans le dossier Programmes car il peut y avoir des problèmes de permission. Pour exécuter Gatling, vous devez au préalable avoir installer un JDK.

Les scripts de lancement Gatling et le plugin Gatling maven utilisent la variable d’environnement JAVA_HOME.

Dans cette section, nous utiliserons Gatling pour tester un simple serveur web hébergé dans le cloud et pour présenter les éléments de base de la DSL.

Dans cet exemple, nous allons utiliser une application intitulée Computer-Database accessible sur http://computer-database.gatling.io. Cette dernière est une simple application CRUD pour la gestion des modèles informatiques.

Pour tester les performances de cette application, nous allons créer des scénarios représentatifs de ce qui se passe réellement lorsque les utilisateurs le parcourent. Voici ce qu’un réel utilisateur ferait avec l’application :

  1. L’utilisateur arrive sur l’application
  2. L’utilisateur recherche « Macbook »
  3. L’utilisateur ouvre l’un des modèles associés
  4. L’utilisateur revient à la page d’accueil
  5. L’utilisateur parcourt les pages
  6. L’utilisateur crée un nouveau modèle

Pour facilier la création du scénario, nous utiliserons l’Enregistreur, un outil fourni avec Gatling qui vous permet d’enregistrer vos actions sur une application Web et de les exporter en tant que scénario Gatling. Cet outil est lancé avec un script situé dans le répertoire bin :

 

Sur Linux/Unix :

$GATLING_HOME/bin/recorder.sh

Sur Windows:

$GATLING_HOME%\bin\recorder.bat

Une fois lancée, l’interface graphique vous permet de configurer comment les requêtes et les réponses seront enregistrées.

Configurez-le avec les options suivantes :

  • Package              :        computerdatabse
  • Nom                     :        BasicSimulation
  • Cochez                :        Follow Redirects? Automatic Referers?
  • Sélectionnez     :        Black list first filter
  • Insérez                :        Black list filters : *\.css, *\.js, *\.ico

Une fois l’Enregistreur configuré, il vous suffit de le lancer et de configurer votre navigateur à utiliser le proxy de Gatling Recorder.

Pour plus d’informations sur l’Enregistreur et la configuration de votre navigateur : https://gatling.io/docs/current/http/recorder/#recorder

 

Nous allons maintenant procéder à l’enregistrement du scénario. Tout simplement naviguez sur votre navigateur :

  1. Entrez le mot clé : « Search »
  2. Allez sur le site : http://computer-gatling.io
  3. Recherchez des modèles avec « Macbook » dans leur nom
  4. Sélectionnez « Macbook pro »
  5. Entrez la balise « Browse »
  6. Retournez sur la page d’accueil
  7. Parcourez les pages du modèle en cliquant sur  le bouton « Next »
  8. Entrez la balise « Edit »
  9. Cliquez sur « Add a new computer »
  10. Remplissez le formulaire
  11. Cliquez sur « Create this computer »

Essayez d’agir comme un vrai utilisateur, ne sautez pas immédiatement d’une page à l’autre sans prendre le temps de lire. Cela rendra votre scénario plus proche du comportement des utilisateurs réels.

Lorsque vous avez terminé la lecture du scénario, cliquez sur « Stop » dans l’interface de l’Enregistreur.

La simulation sera générée dans le dossier : user-files/simulations/computerdatabase de votre installation Gatling sous le nom de BasicSimulation.scala.

 

Voici l’output produit :

Que cela signifie-t-il ?

 

  1. Le package opptionnel
  2. Les imports requises
  3. La déclaration de la classe, qui étend Simulation
  4. La configuration commune à toutes les requêtes HTTP
  5. baseURL qui sera ajouté à toutes les URL relatives
  6. Headers HTTP courants qui seront envoyés avec toutes les demandes
  7. La définition du scenario
  8. Une requête HTTP, nommée request_1
  9. L’URL que cette requête cible avec la méthode GET
  10. Temps de pause-réflexion
  11. Où l’on place les scénarios qui seront lancés dans cette simulation
  12. Déclaration de l’injection dans le scénario « scn »
  13. Attachement de la configuration HTTP

 

# LANCEMENT DE GATLING 

 

Lancer le deuxième script situé dans le répertoire bin :

Sur Linux/Unix :

$GATLING_HOME/bin/gatling.sh

Sur Windows:

$GATLING_HOME%\bin\gatling.bat

 

Vous devriez obtenir un menu avec les différentes simulations :

Choose a simulation number: 

[0] computerdatabase.BasicSimulation

 

[NOTE] Nous avons alors vu comment créer nos propres simulations. Par défaut, Gatling fournit des simulations disponibles dans le répertoire « user-files ». On peut notamment exécuter l’une d’elle afin de vérifier que tout fonctionne correctement.

 

Une fois la génération terminée, nous obtenons l’affichage suivant :

 

L’utilisation d’une CLI (Command-Line Interface) est très pratique pour faire rapidement quelques tests mais elle a ses limites lorsque l’on travaille sur un vrai projet.

On préfère alors utiliser l’une des possibilités d’intégration suivantes :

  • Un plugin Maven officiel : fonctionne bien et suffisant pour un grand nombre de projet Java
  • Un ensemble de plugins Tiers : pour Play2!, SBT et Gradle

 

# RÉSULTATS

 

         Les résultats sont disponibles au format HTML, vous pouvez les consulter en ouvrant le fichier index.html généré.

Voici quelques exemples de données disponibles :

Les indicateurs montrent comment les temps de réponses sont répartis entres les plages standards. Le panneau de droite affiche le nombre de demandes OK / KO.

Les statistiques : Le panneau supérieur présente certaines statistiques standards telles que le minimum, la moyenne, le maximum, les écart-types et pourcentages globalement et par requêtes. Le panneau du bas montre quelques détails sur les demandes ayant échouées.

Les utilisateurs actifs, ce graphique montre les utilisateurs actifs durant la simulation : total et par scénario.

Ce graphique présente la distribution du temps de réponse.

Ce graphique affiche une variété de données : temps de réponse au fil du temps mais uniquement pour les demandes réussies. Comme les demandes échouées peuvent se terminer prématurément ou être causées par des délais d’attendre, elles auront un effet considérable sur le calcul.

Ce graphique présente le nombre de requêtes envoyées par seconde au fil du temps.

 

Ce graphique présente le nombre de réponses reçues par seconde au fil du temps : total, réussies et échouées.

 

Ce graphique est seulement disponible lorsqu’on visite les détails spéficiques à une requête ou un groupe sur l’index.html généré.

Ce graphique montre comment le temps de réponses pour une requête donnée est distribué, en fonction du nombre global de demandes en même temps.

 

# LIENS & RÉFÉRENCES

 

Laisser un commentaire

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