Tutoriel pour découvrir l'écosystème d'Apache JMeter

JMeter Plugins est un ensemble de plugins gratuits et open source améliorant certaines parties de JMeter.

Pour cela il va ajouter un certain nombre de :

• récepteurs ;
• graphiques ;
• fonctions ;
• échantillons ;
• outils ;
• groupe d'unités ;
• compteurs de temps ;
• assertions ;
• protocoles ;
• etc.

Comme nous pouvons le voir, la liste est longue, nous ne présenterons donc que certains plugins.

Commençons par le groupe d'unités Ultimate Thread Group. Ce plugin va nous permettre de contrôler facilement et visuellement notre injection.

Regardons d'un peu plus près le point fort de JMeter Plugins : les graphiques.

Response Times Over Time nous permet de suivre l'évolution des temps de réponse au fil du tir.

De même pour Response Times Percentiles, mais concernant les percentiles.

La même chose pour suivre le nombre d'utilisateurs virtuels avec le graphique Active Threads Over Time.

Si nous voulons suivre l'évolution des codes de retour HTTP au fil du tir, nous utiliserons Response Codes per Second.

Pour vérifier l'impact du nombre d'utilisateurs virtuels sur les temps de réponse, il y a le graphique Response Times vs Threads.

Pour la répartition des temps de réponse, nous utiliserons Response Times Distribution.

Si cela ne suffit toujours pas, il est possible de superposer les graphes à l'aide des données de tous les autres graphes en utilisant Composite Graph.

Pour l'instant nous avons utilisé des graphiques se basant sur les données du test, mais il est possible de récupérer des données externes.

Comme des données JMX (par exemple de votre serveur d'application Java) à l'aide de JMXMon Samples Collector.

Et pour savoir si les problèmes de performance de l'application testée viennent de l'infrastructure, nous pourrons utiliser PerfMon Metrics Collector afin de récupérer les métriques systèmes (CPU, réseau, mémoire, etc.).

S'il y a un problème avec la base de données, DbMon Samples Collector pourra nous aider.

Le tout avec la possibilité de générer les graphiques voulus à la fin de notre test de charge avec Graphs Generator. Méthode préconisée puisque le mode GUI doit être dédié au scripting.

Une autre option consiste à uploader ses résultats sur Loadosophia.org à l'aide de Loadosophia.org Uploader.

Si nous souhaitons connaître le ressenti utilisateur dans le browser (les temps de réponse JMeter n'intègrent pas le rendu dans le browser), nous pourrons utiliser dans notre test :

• l'élément HTTP Request pour injecter massivement la charge ;
• l'élément WebDriverSampler pour obtenir les temps dans le browser

Une problématique qui peut se poser dans le cadre de tirs distribués avec JMeter est la distribution du jeu de données sur les injecteurs. Une solution à ce problème consiste à utiliser Redis et le plugin Redis DataSet. Il est même possible de garantir qu'une donnée une fois utilisée est supprimée du jeu de test.

Comme vous pouvez le voir, cet ensemble de plugins couvre un large périmètre et est très utile dans la vie de tous les jours d'un utilisateur de JMeter.

Cette catégorie répondra au problème d'infrastructure nécessaire pour l'injection de la charge.

En effet lors de certains tests, il peut être nécessaire d'avoir beaucoup de puissance afin de simuler une charge importante.

Il peut être également nécessaire de distribuer l'injection depuis plusieurs endroits du pays ou de la planète.

Dans d'autres cas, pour des tests ponctuels, l'achat de serveurs pour l'injection n'est pas justifié.

Pour cela, une des solutions possibles est l'utilisation de services commerciaux dans le cloud.

II-B-1. BlazeMeter▲

À noter que BlazeMeter est un contributeur actif du projet Apache JMeter à travers les contributions d'Andrei Pokhilko (responsable du projet JMeter-Plugins).

L'utilisation de BlazeMeter est assez simple.

Lorsque nous nous connectons sur le site pour créer un test, un assistant apparaît.

Dans notre cas, nous n'allons pas l'utiliser. Un écran très complet nous permet de créer notre test.

Nous pourrons :

• importer notre script (fichier jmx) avec son jeu de données (fichier csv) ;
• régler le nombre d'utilisateurs et leur localisation géographique ;
• régler notre plan de test (durée du test, durée de la montée en charge, etc.) ;
• simuler une bande passante réseau particulière (4G, ADSL, Fibre, etc.) ;
• nous interfacer avec des outils d'APM (Newrelic, Dynatrace) ;
• surcharger des valeurs de propriétés ;
• etc.

Lançons notre test et suivons son évolution en temps réel.

Une supervision des injecteurs est proposée, ce qui est pratique pour valider de la pertinence de nos résultats.

Une fois notre test fini, un rapport peut être généré.

II-B-2. Flood IO▲

Flood IO est une autre solution qui utilise JMeter pour exécuter des tests de charge dans le cloud.

À noter que Flood.IO a développé un DSL pour JMeter (https://github.com/flood-io/ruby-jmeter) qu'il est possible d'utiliser directement dans l'outil.

Son interface est très simple d'utilisation.

Nous importons d'abord notre script accompagné de son jeu de données.

Puis nous définissons les paramètres de notre test.

Si nécessaire, la partie advanced nous permet d'affiner notre test (simuler une bande passante réseau particulière, surcharger des valeurs de propriétés, etc.).

Lançons notre test et suivons son exécution en temps réel.

Une supervision des injecteurs est proposée.

À la fin de notre test, nous pouvons télécharger notre rapport ainsi que les fichiers de résultats au format CSV et fichiers de log.

II-B-3. Redline 13▲

Redline 13 est une autre solution un peu particulière qui utilise JMeter pour exécuter des tests de charge dans le cloud. En effet il va utiliser notre propre clé AWS (cloud Amazon et bientôt d'autres) afin d'instancier des serveurs et y déployer JMeter et tout le nécessaire (scripts, plugins, jeux de données, etc.) pour exécuter notre test de charge.

La première chose à faire est d'entrer notre clé AWS.

Une fois cela fait, nous nous retrouvons sur une page d'accueil assez simple avec tous les tests exécutés précédemment.

Cliquons sur le bouton « Start a New Test » pour commencer notre test.

Comme nous le voyons, plusieurs types de tests sont possibles :

• test d'URL ;
• test écrit en PHP ou NodeJS ;
• test JMeter ;
• test Gatling.

Choisissons JMeter comme type de tests.

Ici nous pouvons choisir :

• notre script JMeter ;
• le jeu de données associé (ici le fichier uri.csv) ;
• le nombre de serveurs à instancier ;
• la version de JMeter ;
• le nom de notre test.

Dans la partie avancée du plan de test, il est possible de choisir les localisations AWS des serveurs et ainsi inclure plusieurs localisations si nous avons plus d'un serveur à instancier. Ceci nous permet potentiellement de voir le ressenti utilisateur en fonction du réseau, ce genre de besoins est plutôt réservé à des sites web déployés à l'international.

Enfin nous pouvons spécifier des options JMeter à passer aux injecteurs :

Notons au passage que nous pouvons sauvegarder notre plan de test comme modèle pour l'utiliser dans Jenkins avec le plugin Redline13.

Exécutons notre test.

Et suivons-le.

Les métriques de notre scénario sont disponibles.

La supervision des injecteurs est disponible.

À la fin de notre test, il est possible pour chaque métrique de l'exporter au format CSV pour la travailler avec un autre outil.

X> Beaucoup d'autres fonctionnalités sont disponibles, je vous laisse creuser le sujet.

Dernière solution qui a vu le jour, OctoPerf permet d'exécuter un test de charge basé sur JMeter depuis le coud.

OctoPerf dispose d'une interface très simple et sobre.

Plusieurs possibilités sont proposées :

• tester une URL ;
• utiliser un fichier HAR (HTTP Archive) comme script ;
• importer un script JMeter.

Nous choisissons d'importer notre script JMeter.

Une fois l'importation réalisée, Jellly offre une représentation visuelle du script.

Si nécessaire nous pouvons modifier notre script.

Il est même possible d'utiliser la fonctionnalité Règles de corrélation qui est l'équivalent de l'autocorrélation dans LoadRunner (HP) ou bien des paramètres de framework dans NeoLoad (Neotys).

Définissons et importons notre jeu de données.

Créons notre plan de tir.

Notre projet de test de charge est prêt.

Exécutons notre test pour le suivre en temps réel.

De nombreux graphiques sont disponibles.

Une fois notre test fini, un rapport au format PDF est disponible. Ce rapport peut être entièrement personnalisé avec les graphiques souhaités :

• statistiques avancées telles que les percentiles ;
• détail des réponses reçues du serveur en cas d'erreur ;
• etc.

Une autre solution est d'utiliser le plugin gratuit dédié à AWS nommé JMeter EC2 qui permet simplement de :

• démarrer les instances AWS ;
• lancer le tir ;
• récupérer et fusionner les résultats.

Cette solution est l'APM Dynatrace.

Dynatrace permet de suivre la performance de bout en bout à l'aide de sa technologie PurePath. Cela va nous permettre d'aller jusqu'à la ligne de code problématique si un problème de performance est détecté.

Le tout en ayant la possibilité d'avoir une vision globale et visuelle.

Reprenons nos deux critères de sélection.

Comme nous pouvons le voir sur la capture d'écran ci-dessous, plusieurs acteurs entrent en jeu (Java, navigateur Web et serveur Apache httpd).

De nombreuses technologies sont gérées :

• .Net ;
• PHP ;
• C/C++ ;
• Mobile ;
• zOS ;
• NodeJS ;
• etc.

Passons au deuxième point : l'intégration avec JMeter.

L'intégration entre les deux outils se fait par l'ajout d'entêtes HTTP spécifiques à Dynatrace dans les requêtes HTTP de JMeter.

Une fois cela réalisé, observons dans Dynatrace les PurePath désormais renommés comme les transactions de JMeter.

Dès lors, nous avons accès à toute la puissance de Dynatrace pour la supervision et le diagnostic.

Ci-dessous quelques-unes de ses possibilités (non exhaustives) pour le diagnostic.

Réaliser des threads dump.

Réaliser des dumps mémoire.

Connaître les méthodes qui prennent le plus de temps et avoir leur arbre d'appel.

Avoir la répartition des temps de réponse.

Ou encore la possibilité de créer ses propres tableaux de bord.

Une fois notre test de charge réalisé, il est possible de sauvegarder une session Dynatrace contenant toutes les informations (les erreurs, les transactions, les temps de réponse, les PurePath, etc.) afin de nous donner la possibilité :

• de comparer plusieurs tirs ;
• d'analyser les résultats plus tard ;
• d'envoyer les informations à une autre équipe (par exemple les développeurs pour qu'ils puissent approfondir l'analyse).

Il est même possible de réaliser cette action automatiquement à l'aide de l'API REST de Dynatrace.

Et toujours avec l'API REST, il est possible de générer un rapport Dynatrace à la fin du test.

Pour les impatients, il existe un tableau de bord Dynatrace dédié aux tests de charge.

Nous venons de voir un aperçu des possibilités de Dynatrace qui montrent son ROI en termes d'analyse lors d'une campagne de tests de charge.

Loadosophia.org est un service en mode SAAS permettant de stocker et d'analyser le résultat de tests réalisés avec JMeter (à noter qu'Apache Benchmark(ab) et Yandex Tank sont également supportés).

Loadsophia est un service de Blazemeter.

Une fois nos résultats de tests uploadés, un grand nombre de graphiques est généré afin de faciliter l'analyse des résultats.

Pour uploader nos résultats, deux moyens existent :

• le faire par l'intermédiaire du site Web ;
• utiliser le récepteur jp@gc - Loadosophia.org Uploader livré avec JMeter-Plugins.

Nous allons utiliser la deuxième solution.

Pour cela il suffit d'ajouter jp@gc - Loadosophia.org Uploader à notre plan de test et de le configurer.

T> Pour avoir son Upload Token, il suffit de se connecter sur Loadosophia.org et de le récupérer dans la partie Settings de son compte.

Exécutons notre test pour que l'upload des résultats se fasse.

Regardons d'un peu plus près nos résultats. Un résumé du test apparaît.

Comme nous le voyons, de nombreux graphiques sont générés automatiquement.

Nous avons la possibilité de créer un graphique personnalisé.

Le tout peut être téléchargé au format PDF.

Loadosophia.org permet de gagner du temps en générant automatiquement les principaux graphiques nécessaires à notre analyse. De plus, il permet également de stocker les résultats pour comparaison ultérieure.

UbikLoadPack est une solution offrant des plugins pour les protocoles suivants :

• Format HTTP Live Streaming

• GWT-RPC du Framework Google Web Toolkit versions 1.5 à 2.7 (au moment de l'édition de ce livre)

• FLEX/AMF gérant Adobe Flex et Apache Flex

• Java Serialization permettant de simuler des applets ou des applications utilisant Spring Remoting

La solution permet de tester de façon réaliste des applications basées sur ces protocoles, c'est-à-dire en permettant la corrélation par la mise à disposition d'extracteurs et de transformateurs.

Le fonctionnement global des plugins est le suivant :

• avec Enregistreur script de test HTTP(S), vous enregistrez votre navigation sur l'application et créez en quelques minutes le test JMeter ;
• à l'aide de samplers dédiés ou de préprocesseurs, le plugin transforme les requêtes « illisibles » du protocole en XML que vous pouvez ainsi facilement variabiliser puisqu'il est possible d'injecter des variables JMeter par la syntaxe ${variable}

• vous pouvez extraire des réponses « illisibles » (transformées en XML par les PostProcesseurs du plugin) n'importe quelle donnée que vous souhaitez vérifier ou injecter dans la requête suivante

La solution offre également des Renderer/Visualiseur spéciaux intégrés à Arbre de résultats qui vous permettent de déboguer vos scripts en transformant à la volée le format du protocole en XML et de tester vos expressions d'extraction XPath.

Une fois votre script prêt, vous utiliserez alors la démarche du chapitre 3 pour variabiliser votre script, vérifier les réponses et exécuter votre tir comme expliqué dans le chapitre 8.

Pour le protocole HLS, la solution permet de simuler le comportement d'un player HLS sans l'impact en performance des players, nous pourrons ainsi facilement tester des milliers ou centaines de milliers d'utilisateurs avec une infrastructure raisonnable.

Elle gère l'extraction des « chunks » des vidéos HLS, simule la lecture par un « player », et peut même simuler une bande passante.

Enfin elle ajoute des métriques spécifiques aux résultats JMeter qui vous permettent de connaître:

• le temps d'attente de l'utilisateur avant que sa vidéo ne commence (Buffer Fill Time) ;
• le lag, c'est-à-dire les pauses pendant la lecture dues aux ralentissements réseau ou du serveur HLS (Lag Time) ;
• le temps de lecture (Play Time) ;
• le temps de téléchargement (Download Time) ;
• le lag ratio, c'est-à-dire le temps de lag divisé par la durée totale de la vidéo (Lag ratio).

En synthèse, si vous connaissez JMeter, utiliser UbikLoadPack pour ces protocoles particuliers est très intuitif et ne nécessite pas de formation particulière.

À noter qu'UbikLoadPack est un contributeur très actif des projets Apache JMeter et JMeter-Plugins.

Les créateurs du service Flood IO ont pensé à ces personnes en créant un DSL nommé Ruby based DSL for JMeter. Comme son nom l'indique, il est basé sur du Ruby et nous permet d'écrire des scripts JMeter dans notre IDE préféré.

Installer le plugin est aussi simple que:

    gem install ruby-jmeter

Prenons cet exemple (contenu du fichier « montest.rb ») :

    require 'rubygems'
    require 'ruby-jmeter'
        test do
        cookies
        cache clear_each_iteration: true
          threads count: 5, duration: 60, continue_forever: true do
            random_timer 3000
            visit name: 'Accueil', url: 'http://jmeter.apache.org' do
                assert substring: "Further Information About JMeter", scope: 'main'
            end
          end
        end.jmx(file:"./montest.jmx")

Ici nous positionnons :

• le gestionnaire de cookies HTTP ;
• le gestionnaire de cache HTTP, le cache est nettoyé à chaque itération ;
• un groupe d'unités composé de 5 utilisateurs, sa durée est de 60 secondes, et le nombre d'itérations infini ;
• un compteur de temps aléatoire gaussien est positionné, son Délai de décalage basé gaussien est positionné à 3 secondes, nous allons donc faire une pause variable de 3 s avant chaque appel d'Accueil (point suivant) ;
• chaque unité navigue sur la page d'accueil de JMeter (http://jmeter.apache.org), la requête est nommée Accueil ;
• nous vérifions la présence du texte « Further Information About JMeter » (en bas de la page si possible) dans la réponse principale de l'échantillon, l'option utilisée est « Contient (texte brut) » ;
• enfin le fichier jmx qui sera généré par ruby s'appellera « montest.jmx ».

Lançons :

    ruby montest.rb

    I, [2015-09-25T21:54:32.437507 #11545]  INFO -- : Test plan saved to: ./montest.jmx

Le plan suivant est généré :

Ce plugin a plusieurs avantages :

• il offre une vue synthétique du test JMeter ;
• il permet de versionner plus facilement le plan de test dans un gestionnaire de source. En effet, comparer le DSL est plus facile que de le faire avec le format XML de JMeter.

Il sera donc assez adapté à des tests de type Webservice où l'enregistrement a peu d'intérêt.

À noter que le projet github est assez actif avec 14 contributeurs (Pull Requests), 54 releases (octobre 2015) et le parrainage de Flood.IO. La gestion de versions du projet suit celle de JMeter en ajoutant un numéro de patch, ainsi pour JMeter 2.13, la version de ruby-jmeter correspondante est la 2.13.X. Le DSL gère un sous-ensemble des éléments de JMeter liés aux tests de type Web ainsi qu'une partie des éléments de JMeter-Plugins.

I> De nombreux exemples sont disponibles sur le site à l'URL https://github.com/flood-io/ruby-jmeter/tree/master/examples