Apache JMeter de A à Z. Antonio Gomes Rodrigues and Bruno Demion a.k.a. Milamber

Apache JMeter de A à Z Antonio Gomes Rodrigues and Bruno Demion a.k.a. Milamber

Apache JMeter de A à Z Antonio Gomes Rodrigues and Bruno Demion a.k.a. Milamber This book is for sale at http://leanpub.com/apache-jmeter-de-a-z This version was published on 2015-08-07 This is a Leanpub book. Leanpub empowers authors and publishers with the Lean Publishing process. Lean Publishing is the act of publishing an in-progress ebook using lightweight tools and many iterations to get reader feedback, pivot until you have the right book and build traction once you do. 2014-2015 Antonio Gomes Rodrigues and Bruno Demion a.k.a. Milamber

Table des matières Tester un serveur de bases de données........................... 1 Un peu de théorie...................................... 1 Mise en place avec JMeter................................. 2 Méthodologie........................................ 4 Mise en pratique avec JMeter................................ 5 Conclusion.......................................... 28 L écosystème d Apache JMeter................................ 29 Introduction......................................... 29 Plugin polyvalent...................................... 29 JMeter dans le cloud.................................... 39 DevOps........................................... 40 Aide à la supervision et au diagnostic........................... 40 D autres protocoles..................................... 47 DSL (Domain specific language).............................. 53 Conclusion.......................................... 53

Tester un serveur de bases de données Un peu de théorie De nos jours, l architecture d un moteur de base est devenu assez complexe comme le mon tre le schéma ci-dessous (et encore ce n est qu une description simplifiée de l architecture d Oracle). Description simplifiée de l architecture d Oracle Chaque partie de cette architecture peut être paramétrée afin de s adapter au mieux à l utilisation de la base de données. Si on ajoute que les données stockées en base sont l un des éléments les plus importants d une application et celui qui pose le plus de problème de performance, on comprend l importance de faire des tests de charge sur le serveur de bases de données.

Tester un serveur de bases de données 2 Pour ceux qui ne sont pas encore convaincus par l importance de faire du tuning de l architecture du moteur de base de données, ci dessous un exemple de temps de réponse d une requête SQL sur un Oracle sans tuning (la SGA (un des caches de la base de données Oracle) n est pas bien configurée) par rapport à un Oracle optimisé (on a augmenté la taille de la SGA pour qu elle soit cohérente par rapport à la taille des données stockées en base). Importance du SGA Comme on peut le voir, cela vaut le coût de passer un peu de temps à optimiser Oracle à l aide d un test de charge. Regardons maintenant comment JMeter permet de tester un serveur de base de données. Mise en place avec JMeter JMeter étant un programme Java, l accès à une base de données se fait à l aide du protocole JDBC. La première chose à faire est donc de mettre le pilote JDBC dans le ClassPath de JMeter si ce n est pas déjà fait (en pratique, déposez le fichier pilote.jar dans JMETER_HOME/lib/). Une fois cela fait, il faut configurer la connexion à la base avec l élément Configuration de connexion JDBC. Cela va nous permettre de configurer la chaîne de connexion à notre base de données (URL, port, identifiant de connexion, mot de passe, etc.).

Tester un serveur de bases de données 3 Configuration de connexion JDBC Cet élément est composé de quatre parties nommées Nom de liaison du pool, Configuration du pool de connexions, Validation des connexions par le pool et Configuration de connexion à la base de données. Leurs noms étant parlant, nous ne nous attarderons donc pas plus. Cependant il est important de faire attention aux parties Configuration du pool de connexions et Validation des connexions par le pool afin de ne pas surcharger JMeter (en particulier le nombre maximum de connexions) et la base de données (niveau d isolation de la Transaction, auto commit et requête de validation). Bien sûr, il est possible d avoir plusieurs éléments Configuration de connexion JDBC qui pointent sur plusieurs bases de données. Maintenant on peut passer aux requêtes SQL elles-mêmes à l aide de l élément Requête JDBC.

Tester un serveur de bases de données 4 Requête JDBC Dans un premier temps on choisit sur quelle base de données les requêtes vont être utilisées à l aide du champ Nom de liaison (nom défini dans l élément Configuration de connexion JDBC). Comme on peut le voir dans la liste Type de requête, tous les types de requêtes peuvent être réalisés (UPDATE, SELECT, DELETE, INSERT, appel de procédure stockée, etc.). À l aide de ces deux éléments, on peut tester tout type de base de données (la seule exigence est la présence d un pilote JDBC pour la base de données cible) avec toutes les requêtes SQL imaginables. Méthodologie Avant de passer à des exemples concrets, il est important d avoir une méthodologie afin de réaliser des tests pertinents. Quelques conseils clés qu il est préférable d intégrer à votre processus : Une chose importante lors d un test d une base de données est qu elle doit être la plus isoproduction possible.

Tester un serveur de bases de données 5 Par iso-production il faut comprendre deux choses : Le paramétrage du moteur de base de données doit être identique à celui en production (s il existe). Le volume des données en base doit être lui aussi le plus proche de la réalité (le plus simple est d avoir une sauvegarde de ce qu il y a en production ou si on part de zéro, d avoir une idée de la future volumétrie). Pour les sceptiques/curieux, on peut voir sur le graphique suivant, le temps de réponse de la même requête SQL exécutée sur des volumes de données différents. Importance du volume de données Maintenant que nous avons une base de données iso-production, penchons-nous sur le plan de test. Dans notre plan de test il faut prendre en compte la durée des tests et la diversité des requêtes d entrées. De nos jours, il y a forcément des caches dans l architecture que l on va tester (que cela soit au niveau du moteur de base de données ou au niveau d autres composants de l architecture technique). Les caches sont conçus pour éviter que les mêmes traitements lourds (requêtes SQL, etc.) avec les mêmes paramètres (valeurs des paramètres, etc.) soient exécutés à chaque fois. Pour cela un cache stocke le résultat du traitement lourd. Cela implique que le cache sera inutile si la durée de test est trop courte, car il n aura pas le temps de se remplir pour être utile. Et le cache sera trop utilisé si la diversité des requêtes envoyées (et donc leurs types et leurs paramètres) est trop réduites. Inversement le cache sera inutile si le jeu de données est trop diversifié. Mise en pratique avec JMeter Passons à la pratique.

Tester un serveur de bases de données 6 Exemple 1 : test de charge d une base de données Démarrons par un exemple simple (que nous complexifierons au fur et à mesure) qui consiste à tester une base de données sous MySQL à l aide d une requête SQL. Occupons-nous dans un premier temps des requêtes SQL de type SELECT. Commençons par configurer notre connexion à MySQL à l aide de l élément Configuration de connexion JDBC. Pour MySQL, l URL de la base de données doit être de la forme jdbc :mysql ://host :port/dbnom et la classe de pilote JDBC égale à com.mysql.jdbc.driver. Dans notre cas, la base MySQL est installée en local et par défaut sur la même machine que JMeter (à éviter absolument lors de vrais tests), son URL sera jdbc :mysql ://localhost :3306/test On règle à zéro le nombre maximum de connexions afin que chaque thread ait sa propre connexion. Configuration de connexion JDBC Maintenant ajoutons une Requête JDBC afin d exécuter notre fameux SELECT. Mettre le nom de la connexion qui a été défini avant. Choisir Select Statement comme type de requête SQL Remplir le champ Requête avec notre select (ici select nom,prenom from Clients where nom like D% ).

Tester un serveur de bases de données 7 Requête JDBC Ajouter une assertion afin de contrôler la bonne exécution de notre requête. Dans notre cas, lorsqu il y a une erreur d exécution, la réponse contiendra l expression exceptions. Assertion Dans l état actuel, le script ne couvrira qu une partie infime d un bon plan de test, puisque avec une seule requête SQL, on testera surtout les caches. Heureusement on nous a donné une liste des principales requêtes SQL de type SELECT exécutées. Un moyen simple d intégrer ces nouvelles requêtes à notre script est d utiliser un élément Source de données CSV. Pour cela on va mettre toutes les requêtes dans un fichier CSV. Extrait du fichier CSV :

Tester un serveur de bases de données 8 req_sql select nom,prenom from Clients where nom like 'D%' select nom from Clients select nom,prenom from Clients where sex = 'MALE' select nom,prenom from Clients where nom like 'T%' select nom,prenom from Clients where sex = 'FEMALE' 8' select nom,prenom,mail,code_postal from Clients where code_postal = '5841\ On va renseigner le nom de notre fichier CSV dans le champ Nom de fichier de l élément Source de données CSV. Ne pas oublier de changer la valeur du délimiteur de virgule en par exemple point-virgule afin qu il n y ait pas de problème avec les virgules qui composent nos requêtes. Ici on n a pas besoin de définir le nom de la variable où sera stockée la requête afin d être utilisée par la suite, car elle existe déjà dans notre fichier CSV. Source de données CSV Il nous ne reste plus qu à remplacer la requête dans le champ Requête de l élément Requête JDBC par notre variable ${req_sql}.

Tester un serveur de bases de données 9 Utilisation de notre variable *${req_sql} dans Requête JDBC Afin de vérifier que cela fonctionnne, on ajoute un élément Arbre de résultats à notre plan de test (ne pas oublier de le désactiver pour la suite lorsqu on fera un test de charge). Arbre de résultats Voila qui est beaucoup mieux mais les requêtes restent statiques et au bout d un moment (plus ou moins long en fonction du nombre de requêtes SQL dans le fichier CSV), elles se retrouveront toutes dans le cache. Afin d éviter ce problème et de rendre notre test plus réaliste, on va rendre dynamiques nos

Tester un serveur de bases de données 10 requêtes SQL. Pour commencer on va regrouper nos requêtes par famille ayant la même forme syntaxique. Dans notre cas nous avons deux familles : select XXXXXXX from XXXXX where XXXXX select XXXXXXX from XXXXX On aura donc besoin de deux Requêtes JDBC. Maintenant, pour chaque groupe de requête on va noter ce qui peut être variabilisé. Par exemple : select nom, prenom from Clients where nom like 'D%' deviendra : select {liste_selection} from {table} where {clause where} Toutes ces variables seront dans un fichier CSV. Extrait du fichier CSV : liste_selection_grp1;table_grp1;clause_where_grp1 nom,prenom;clients;nom like 'D%' nom,prenom;clients;sex = 'MALE' nom,prenom;clients;nom like 'T%' nom,prenom;clients;sex = 'FEMALE' nom,prenom,mail,code_postal;clients;code_postal = '58418' On modifie notre élément Source de données CSV afin qu il pointe sur notre nouveau fichier CSV. Enfin on modifie notre champ requête qui devient : select ${liste_selection_grp1} from ${table_grp1} where ${clause_where_gr\ p1}

Tester un serveur de bases de données 11 Notre requête SQL On fait la même chose pour le deuxième groupe de requête SQL. Extrait du fichier CSV : liste_selection_grp2;table_grp2 nom,prenom;clients Ajoutons l élément Contrôleur d Ordre aléatoire afin d ajouter encore un peu plus de réalisme en simulant des utilisateurs avec des comportements différents. Contrôleur d Ordre aléatoire Avec encore un peu d effort, on peut encore rendre plus réaliste les clauses WHERE de nos requêtes SQL. On remarque que la clause WHERE peut être séparée en plusieurs parties. {clause where} = {clause where gauche} {clause where condition} {clause w\ here droite} Avec le même méthodologie que précédemment, on peut affiner notre fichier CSV et notre Requête JDBC et ainsi multiplier les requêtes possibles avec un jeu de données réduit (il suffira d utiliser un script qui génère notre fichier CSV en combinant les valeurs possibles). Par exemple. Extrait du fichier CSV :

Tester un serveur de bases de données 12 liste_selection_grp1;table_grp1;clause_where_grp1 nom,prenom;clients;nom like 'D%' nom,prenom,mail,code_postal;clients;code_postal = '58418' Deviens : Extrait du fichier CSV : liste_selection_grp1;table_grp1;clause_where_gauche_grp1;clause_where_con\ dition_grp1;clause_where_droite_grp1 nom,prenom;clients;nom;like;'d%' nom,prenom,mail,code_postal;clients;code_postal;=;'58418' nom,prenom;clients;code_postal;=;'5841' nom,prenom,mail,code_postal;clients;nom;like;'d%' Requête JDBC utilisant notre fichier CSV Dans la majorité des cas, il y a des utilisateurs avec des droits de modification (on va les appeler administrateurs) qu il faudra simuler. Rien de plus simple avec JMeter. Afin de séparer les deux types d utilisateurs, on va créer un autre Groupe d unités. Un des avantages de faire cela est qu on peut paramétrer de manière fine chaque groupe. Par exemple si on sait qu il y a 24 % d utilisateurs qui ont des droits de modification, il sera facile de trouver la valeur du Nombre d unités pour chaque groupe. Afin d éviter de faire des UPDATE qui ne mettent rien à jour, les conditions de nos requêtes UPDATE seront les résultats de requêtes SQL exécutés juste avant nos UPDATE. Imaginons que ces utilisateurs puissent modifier le numéro de téléphone des clients. Dans un premier temps nous devons récupérer l identifiant de la personne dont le numéro de téléphone va être modifié.

Tester un serveur de bases de données 13 Utilisons un élément Requête JDBC afin d exécuter cette requête SQL. On pourra prendre select id_client from Clients where nom like F% comme requête SQL (je vous laisse appliquer ce que l on vient d apprendre pour rendre plus dynamique cette requête SQL). Ne pas oublier de récupérer les résultats de la requête SQL. Requête JDBC Comme on peut le voir, la requête nous récupère plusieurs identifiants. Résultat de notre requête SQL On a le nombre de réponse dans la variable identifiant_client_# On va choisir un identifiant au hasard dans la liste retournée. Pour cela on va utiliser la fonction

Tester un serveur de bases de données 14 Random de JMeter. La formule ${ Random(1,${identifiant_client_#},identifiant_client_final)} mis dans un échantillon BeanShell nous permettra de réaliser ce que l on veut en mettant l identifiant dans la variable identifiant_client_final. échantillon BeanShell Maintenant que l on a notre identifiant de client, il nous faut un nouveau numéro de téléphone. Utilisons l élément Variable aléatoire. Variable aléatoire Il ne nous reste plus qu à utiliser la variable identifiant_client_final et notre nouveau numéro de téléphone dans notre update à l aide d un autre élément Requête JDBC. Notre UPDATE sera : update Clients set telephone_fixe = ${num_tel} where id_client = ${identi\ fiant_client_final}

Tester un serveur de bases de données 15 Requête JDBC On va prendre en compte que les administrateurs font aussi des requêtes SQL de type SELECT. Comme on a de la chance, on connaît la proportion des SELECT et des UPDATE. Afin d implémenter cette proportion on va utiliser l élément Contrôleur Débit de JMeter. Par exemple ici, on définit que les requêtes UPDATE représentent 30% des requêtes totales. Contrôleur Débi On peut vérifier à l aide d un Rapport agrégé que cela est bien respecté (j ai regroupé les requêtes à l aide d un Contrôleur Transaction afin de faciliter la lecture des résultats). Rapport agrégé

Tester un serveur de bases de données 16 Une bonne pratique dans le développement logiciel est la philosophie DRY (Don t Repeat Yourself). Malheureusement si on regarde notre dernière modification du script, on peut voir qu il y a des duplications dans la partie du script qui exécute les requêtes SELECT. Duplications dans la partie du script Pour éviter cette duplication, on va utiliser l élément Contrôleur Inclusion qui nous permet d inclure un script dans un autre script. La première chose à faire est de sauvegarder la partie dupliquée dans un fichier au format JMeter. Sauvegarder la partie dupliquée Maintenant il suffit de remplacer dans le script les parties dupliquées par des Contrôleur Inclusion.

Tester un serveur de bases de données 17 Et les faire pointer sur notre script sauvegardé précédemment. Contrôleur Inclusion On aurait pu s arrêter la tout en ayant répondu aux besoins d un test de charge de notre serveur de base de données mais comme je pense que l industrialisation des tests est quelque chose d important, nous allons faire quelques modifications. Ceci aura pour but de faciliter l intégration de notre script dans une usine logicielle. Le tout à l aide de la fonction ${ P(xxx,yyy)} avec xxx le nom de la variable et yyy sa valeur par défaut. Par exemple pour le groupe d unités «Administrateurs». Groupe d unités Administrateurs Ici on définit que par défaut il y a une unité qui exécute une itération et que la durée de montée en charge est d une seconde.

Tester un serveur de bases de données 18 Lors de l exécution de JMeter en ligne de commande, si l on veut changer les valeurs de ces paramètres il suffira d ajouter -J{nom de la variable}={valeur de la variable}. Par exemple. jmeter -n -l resultats.csv -t scenario.jmx -JnbUnites=10 -JrampUp=20 -Jnb\ Iterations=100 Notre plan de test enfin complet. Notre plan de test Exemple 2 : Preuve de faisabilité Dans le tuning SQL, les index tiennent une bonne place mais comme souvent il y a un coût. Pour démontrer ce coût, on va réaliser un POC (Proof Of Concept = Preuve de faisabilité) à l aide de JMeter. Cette fois ci, notre test sera réalisé sur Oracle 11g Express Edition (ne pas oublier d ajouter les drivers JDBC d Oracle dans le ClassPath de JMeter). Notre plan de test final ressemblera à celui-ci.

Tester un serveur de bases de données 19 Notre plan de test final Commençons par définir la connexion à Oracle à l aide de l élément Configuration de connexion JDBC. Connexion à Oracle à l aide de l élément Configuration de connexion JDBC Dorénavant on peut se connecter à notre base de données mais malheureusement elle est vide. Résolvons ce problème grâce à l élément Groupe d unités de début qui va nous permettre d exécuter des commandes au début du test. Ajoutons-lui un élément Appel de processus système afin de remplir cette base de données (par

Tester un serveur de bases de données 20 le chargement d une sauvegarde, par la création de données à l aide d outils/de commandes SQL, etc.). Afin d être sûr que les statistiques de notre base de données soient à jour, nous allons demander à Oracle de le faire par la procédure SQL dbms_stats.gather_table_stats( SYSTEM, Clients,cascade TRUE). Comme pour l exemple précédent, on va utiliser l élément Requête JDBC. L appel d une procédure SQL pour Oracle avec cet élément se fait de la manière suivante. Le type de requête SQL doit être à Callable Statement. Le champ Requête doit être. begin {call proçedure SQL} end; Dans notre cas on aura. Requête JDBC Ne pas oublier de tester la réponse avec un élément Assertion Réponse. En cas d erreur, Oracle retourne un code d erreur commençant par ORA-

Tester un serveur de bases de données 21 Notre base de données est prête. Assertion Réponse On veut que notre test tourne tant qu il y a des indexes à créer. Pour cela nous allons utiliser un élément Groupe d unités dont le nombre d itérations sera égal à l infini et le nombre d unités à 1. Groupe d unités Les requêtes de création d index seront dans un fichier CSV. Et pour arrêter notre test à la fin du fichier CSV (et donc à la dernière création d index), il suffira de le préciser dans l élément Source de données CSV.

Tester un serveur de bases de données 22 Source de données CSV Maintenant passons à l exécution de nos requêtes SELECT. À l aide de l élément Contrôleur Boucle nous allons réaliser dix requêtes afin d avoir des temps de réponses plus précis. Il suffit d ajouter notre requête SELECT. Contrôleur Boucle Ajout de notre requête SELECT Faisons de même pour les UPDATE. Mais cette fois-ci nous allons utiliser des Prepared Update Statement comme type de requête.

Tester un serveur de bases de données 23 Notre UPDATE Il est temps de créer notre premier index automatiquement. Encore une fois, nous utiliserons l élément Requête JDBC. La requête SQL de création des indexes sera directement récupérée à l aide de la variable ${Create_Index_SQL} du fichier CSV défini précédemment. Création des indexes Ne pas oublier de mettre à jour les statistiques après la création de l index. Pour l instant il est impossible d analyser de manière fine le résultat du script, car il nous manque deux informations dans le fichier de résultat de JMeter. La première information est le nombre d index qui sera récupéré à l aide d un élément Echantillon BeanShell associé à la fonction counter.

Tester un serveur de bases de données 24 Calcul du nombre d index crée La deuxième information est la requête SQL de création de l index et elle est déjà dans la variable ${Create_Index_SQL}. Voilà qui est beaucoup mieux mais si on récupère un fichier de résultat de l exécution de notre test, ces deux informations n y sont pas. Pour les ajouter, il faut utiliser la propriété sample_variables du fichier properties de JMeter de la manière suivante. # Optional list of JMeter variable names whose values are to be saved in \ the result data files. # Use commas to separate the names. For example: sample_variables=iteration_number,create_index_sql Ceci conclue notre script de test. Exemple 3 : ETL Dans ce dernier exemple, nous allons utiliser JMeter comme un ETL (Extract Transform Load) pour nous permettre de transférer des données d une base de données à une autre en y appliquant des transformations. En particulier on va anonymiser les colonnes nom et telephone_mobile d une table Clients. Dans un premier temps, définissons nos connexions aux deux bases de données à l aide de l élément Configuration de connexion JDBC. Configuration de connexion JDBC* Afin de générer un nouveau numéro de téléphone, utilisons l élément Variable aléatoire.

Tester un serveur de bases de données 25 Variable aléatoire Pour le nouveau nom nous utiliserons un élément Echantillon BeanShell avec la fonction : ${ RandomString(20,ABCDEFGHIJKLMNOPQRSTUVWXTZabcdefghiklmnopqrstuvwxyz,n\ ouveau_nom)} Un nouveau nom de vingt caractères sera stocké dans le variable nouveau_nom. Création d un nom de manière aléatoire Commençons par récupérer les valeurs dans la base de données source (dans notre cas on ne récupérera que certaines colonnes d une table) à l aide d un élément Requête JDBC.

Tester un serveur de bases de données 26 Plusieurs lignes seront récupérées. Récupération des valeurs dans la base de données source id_client_1=1 id_client_2=2 id_client_3=3 id_client_4=4... mail_1=florenceroberts@hotmail.com mail_2=jennifer_lane@yahoo.com mail_3=wramos@ldjle.org... Maintenant il faut parcourir chaque ligne récupérée avec l élément Contrôleur Pour chaque (ForEach).

Tester un serveur de bases de données 27 Contrôleur Pour chaque (ForEach) Comme on peut le voir on ne peut boucler que sur une variable (ici on a choisi id_client) et donc on perd le lien avec les autres valeurs de la même ligne (prenom, mail, etc.). Par exemple, id_client_1 est associé avec prenom_1, mail_1, sex_1 et salutation_1. Heureusement on peut facilement re créer le lien entre les variables de la même ligne avec l élément Compteur et la fonction ${ V(xxx_${yyyyy})} Le compteur va nous permettre de générer un entier incrémenté de 1 à chaque itération de la boucle ForEach (on aura 1 puis 2 puis 3 ). Notre compteur Puis la fonction ${ V(xxx_${yyy})} concaténera la chaîne de caractère xxx_ avec la valeur de la variable yyy. Par exemple ${ V(prenom_${compteur})} retournera prenom_1 si compteur est égal à un. Fonction qu on utilisera dans notre requête SQL d insertion dans la base de données cible.

Tester un serveur de bases de données 28 Notre requête SQL d insertion Au final notre plan de test ressemblera à celui-ci. Notre plan de test Conclusion Comme on a pu le voir, réaliser un test de charge d une base de données à l aide de JMeter est possible sans grande difficulté. Les possibilités de JMeter permettent en plus de rendre un test de charge réaliste, de réaliser à peu près tous ce qui vous passe par la tête.

L écosystème d Apache JMeter L écosystème de JMeter JMeter dispose d un éco système foisonnant, aussi comme le dit Bregson, «Choisir, donc exclure». nous avons donc dû faire des choix subjectifs. A vous de découvrir et approfondir les librairies que nous avons écartées. Introduction Comme nous avons pu le voir dans les chapitres précédents, JMeter est assez riche nativement, mais les technologies et les besoins évoluant, JMeter peut dans certains cas ne pas suffire. Difficulté résolue par son écosystème dont l existence est possible grâce à sa licence Apache et son architecture modulaire. Dans ce chapitre, nous verrons les principaux plugins, services et outils permettant de compléter JMeter afin de répondre à tous les défis que nous rencontrerons. Plugin polyvalent Commençons par le plugin le plus connu et le plus polyvalent : JMeter Plugins. JMeter Plugins JMeter Plugins est un ensemble de plugins gratuits et open source améliorant certaines parties de JMeter et disponible sur http ://jmeter-plugins.org/. 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.

L écosystème d Apache JMeter 30 Comme nous pouvons le voir, la liste est longue, nous ne présenterons donc que de 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. Ultimate Thread Group 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.

L écosystème d Apache JMeter 31 Response Times Over Time De même pour Response Times Percentiles mais concernant les percentiles. Response Times Percentiles

L écosystème d Apache JMeter 32 La même chose pour suivre le nombre d utilisateurs virtuels avec le graphique Active Threads Over Time. 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.

L écosystème d Apache JMeter 33 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.

L écosystème d Apache JMeter 34 Response Times vs Threads Pour la répartition des temps de réponse, nous utiliserons Response Times Distribution. Response Times Distribution

L écosystème d Apache JMeter 35 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. 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.

L écosystème d Apache JMeter 36 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.). PerfMon Metrics Collector S il y a un problème avec la base de données, DbMon Samples Collector pourra nous aider.

L écosystème d Apache JMeter 37 DbMon Samples Collecto 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. Graphs Generator Une autre option consiste à uploader ses résultats sur Loadosophia.org à l aide de Loadosophia.org Uploader.

L écosystème d Apache JMeter 38 Loadosophia.org Uploader Si nous souhaitons connaître le ressenti utilisateur dans le Browser (Les temps de réponses JMeter n intègrent pas le rendu dans le browser), on pourra utiliser dans son test : L élément HTTP Request pour injecter massivement la charge L élément WebDriverSampler pour obtenir les temps dans le browser Web Driver Sampler 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 est d 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.

L écosystème d Apache JMeter 39 Redis Plugin 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. JMeter dans le cloud 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 autre cas, pour des tests ponctuels, l achat de serveur pour l injection n est pas justifié. Pour cela, une des solutions possible est l utilisation de services commerciaux dans le cloud. BlazeMeter http ://blazemeter.com/ A noter que BlazeMeter est un contributeur actif du projet Apache JMeter à travers les contributions d Andrei Pokhilko (Responsable du projet JMeter-Plugins)

L écosystème d Apache JMeter 40 Flood IO https ://flood.io/ Redline 13 https ://www.redline13.com/ Jellly.IO https ://jellly.io/ JMeter EC2 Une autre solution est d utiliser le plugin gratuit dédié à AWS https ://github.com/oliverlloyd/jmeterec2 qui permet simplement de : Démarrer les instances AWS Lancer le tir Récupérer et fusionner les résultats DevOps Plus un problème de performance est détecté et corrigé tard, plus son coût a des chances d être élevés. C est pour cela qu il est conseillé de faire des tests de charge le plus tôt possible en ayant quand même une application mature et un environnement représentatif en terme de données. Un chapitre entier est consacré à l intégration de JMeter dans le monde DevOps avec les plugins Jenkins Performance Plugin et JMeter Maven Plugin. Aide à la supervision et au diagnostic Lors d une campagne de test de charge si la supervision n est pas à la hauteur ou pire inexistante, la phase d analyse risque d être longue et/ou peu productive. Pour éviter ce souci il existe de nombreux outils (APM, profiler, etc.). Afin d être le plus productif, deux critères de choix sont importants : être multi technologies afin de couvrir des systèmes complexes ; s intégrer facilement à JMeter afin de faire facilement le lien entre l injection et son impact sur le système testé. Il existe une solution répondant à ces deux critères.

L écosystème d Apache JMeter 41 Dynatrace APM 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é. Dynatrace PurePath Le tout en ayant la possibilité d avoir une vision globale et visuelle. Reprenons nos deux critères de sélection. Dynatrace Transaction Flow Comme on peut le voir sur la capture d écran ci-dessous, plusieurs technologies sont supportées (ici on a du Java, du navigateur Web et de l Apache httpd).

L écosystème d Apache JMeter 42 De nombreuses technologies sont gérées : Dynatrace Transaction Flox multi technologies.net PHP C/C++ Mobile zos NodeJS etc. Passons au deuxième point : l intégration avec JMeter. L intégration entre les deux outil se fait par l ajout d entêtes HTTP spécifiques à Dynatrace dans les requêtes HTTP de JMeter. Dynatrace entête HTTP spécifique Une fois cela réalisé, on se retrouve, dans Dynatrace, avec les PurePath renommés comme les transactions de JMeter. Dynatrace Tagged Wevb Requests

L écosystème d Apache JMeter 43 Dynatrace PurePath Dès lors, on a accès à toute la puissance de Dynatrace pour la supervision et le diagnostic. Ci-dessous quelques possibilités (non exhaustives) de Dynatrace pour le diagnostic. Réaliser des threads dump. Réaliser des dumps mémoire. Theads Dump

L écosystème d Apache JMeter 44 Memory Dump 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. Dynatrace Method Hotspots

L écosystème d Apache JMeter 45 Dynatrace Response Time Hotspots Ou encore la possibilité de faire ses propres tableaux de bord. Dynatrace Custom Dashboard 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 ;

L écosystème d Apache JMeter 46 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. Dynatrace REST API Et toujours avec l API REST il est possible de générer un rapport Dynatrace à la fin du test. Dynatrace REST API Pour les impatients, il existe un tableau de bord Dynatrace dédié aux tests de charge.

L écosystème d Apache JMeter 47 Dynatrace Load Test Overview Nous venons de voir un aperçu de Dynatrace, mais on peut déjà deviner le gain de temps et d énergie qu il apportera lors d une campagne de test de charge. Loadosophia D autres protocoles Malgré le nombre élevé de protocoles supportés par Apache JMeter, on peut rencontrer des applications basées sur des protocoles non supportés (ou vouloir augmenter sa productivité en utilisant des plugins plus adaptés). Heureusement de nombreux plugins (en plus des ceux de JMeter plugins vu précédemment) existent. Ubik load pack UbikLoadPack¹ est une solution offrant des plugins pour les protocoles suivants : Format [HTTP Live Streaming] (https ://en.wikipedia.org/wiki/http_live_streaming) ¹http://ubikloadpack.com/

L écosystème d Apache JMeter 48 Apple HTTP Live Streaming GWT-RPC du Framework [Google Web Toolkit] (http ://www.gwtproject.org) versions 1.5 à 2.7 (au moment de l édition de ce livre) GWTRPC FLEX/AMF gérant Adobe Flex et Apache Flex

L écosystème d Apache JMeter 49 FLEX/AMF 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. A l aide de samplers dédiés ou de Pre-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}

L écosystème d Apache JMeter 50 Requête GWT représentée en XML Vous pouvez extraire des réponses «illisibles» (transformées en XML par les Post- Processeurs du plugin) n importe quelle donnée que vous souhaitez vérifier ou injecter dans la requête suivante

L écosystème d Apache JMeter 51 Transformer une réponse en XML et la stocker dans la variable «result» La solution offre également des Renderer/Visualiseur spéciaux intégrés à Arbre de résultats qui vous permettent de débugger vos scripts en transformant à la volée le format du protocole en XML et de tester vos expressions d extraction XPath.

L écosystème d Apache JMeter 52 GWT XPATH TESTER 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, on pourra 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éseaux 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.

L écosystème d Apache JMeter 53 A noter qu UbikLoadPack est un contributeur très actif des projets Apache JMeter et JMeter- Plugins. DSL (Domain specific language) Pour ceux qui n aiment pas l interface graphique de JMeter et préfèrent coder directement leur script avec un langage de programmation dans leur IDE (ou pour les habitués de LoadRunner), il existe une solution. Ruby based DSL for JMeter 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é. https ://github.com/flood-io/ruby-jmeter Conclusion Cette liste de plugins n est qu un échantillon, mais on peut déjà voir toutes les possibilités ajoutées à JMeter. Ce qui le rend comparable à n importe quel outil commercial.