Les tests de charge avec JMeter 2/4

JMeter logo

Les scénarios sont au point, il faut maintenant procéder aux tests de charge proprement dits.

Il faut envisager 3 objectifs possibles pour vos tests

  1. vérifier que votre infrastructure tient la charge sous un trafic donné
  2. optimiser votre infrastructure et avoir des métriques selon l’architecture
  3. trouver les limites de votre infrastructure

Bien souvent, vous allez retrouver un mélange de ces 3 cas au fur et à mesure de vos tests. Inutile de préciser que chercher les limites est la dernière étape, lorsqu’on a déjà fait tous les tests possibles auparavant. Bien souvent, on arrive aux limites de l’infrastructure lors des premiers essais sans nécessairement s’en apercevoir.

Donc les essais suivants n’apportent pas nécessairement d’informations supplémentaires. Il est donc nécessaire d’avoir une méthodologie des plus strictes en s’assurant à chaque « tir » que les composants fonctionnent correctement (vérifier les mises en cache, les erreurs, etc…) et que le tir correspond bien aux hypothèses. C’est d’ailleurs souvent quand on regarde les résultats qu’on se rend compte qu’un composants n’avait pas les bons paramètres, que le cache ne fonctionnait pas convenablement, etc…

Et comme la phase d’optimisation peut également nécessiter quelques tests surtout si on veut faire des comparaisons correctes, il faut imaginer que les tests aux limites arriveront bien plus tard.

Avec JMeter 5.4 la grande nouveauté c’est la création d’un rapport HTML !!!

Avant, on utilisait les graphes des listener qu’on ajoutait au Thread plan. On récupérait le données des tirs dans un fichier CSV, et on affichait le graphe dans JMeter. Mais très souvent, c’était une opération fastidieuse, car le graphe s’affichait dans JMeter à l’intérieur du panneau de droite, avec une lecture difficile du graphe.

C’est désormais de l’histoire ancienne, car le générateur de rapport HTML, comme son nom l’indique génère du HTML, qu’on va pouvoir afficher dans un navigateur. Et en plus, ce générateur produit tous les graphes intéressants avec un seul fichier CSV, graphes qu’on peut sauvegarder sous format PNG.

On génère le fichier CSV lors du test en ligne de commande avec l’option -l . En supposant que notre scénario s’appelle scenario.jmx et qu’on n’a aucun listener activé et qu’aucun n’écrit dans un fichier. Tout se passe lors du lancement en ligne de commande :

Une fois le test terminé, on a un fichier de données scenario.csv qui permet de faire le rapport.

Avant de faire le rapport, il faut créer un répertoire vide, par exemple ~/Documents/scenario qui va contenir tout le HTML du rapport.
Il faut également préciser un fichier user.properties dans lequel on pourrait, entre autres, filtrer des lignes du fichier CSV. Un exemple de user.properties est fourni dans le répertoire jmeter/bin . Il suffit de le copier dans le répertoire ~/Documents pour en avoir un prêt à l’emploi.

On lance jmeter uniquement avec le scénario en mode graphique et on va dans le menu « Tools → Generate HTML Report » dans lequel on fournit nos données

Dans le répertoire du rapport, ~/Documents/scenario on trouve un fichier index.html qui nous permettra d’afficher les graphes :

On peut afficher les différents graphes JMeter, on peut zoomer, supprimer des série et sauvegarder les graphes en PNG en cliquant sur la clé à molettes.

Graphe du nombre de threads lancés en fonction du temps

Pour voir le détail des métriques et du test des pages statiques de WordPress, je vous renvoie à la série d’articles : Booster son WordPress avec Varnish.

Par contre, l’aventure JMeter se poursuit avec la mise au point des scénarios sur des pages dynamiques, c’est à dire sur des formulaires et des pages dépendantes d’une session.

Site officiel de JMeter : https://jmeter.apache.org/