Tutoriel pour tester la charge d'une base de données avec Apache JMeter

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.

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%').

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.

Dans l'état actuel, le script ne couvrira qu'une partie infime d'un bon plan de test, puisqu'avec une seule requête SQL, on testera surtout les caches.

Heureusement, nous disposons d'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 :

    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' 
    select nom,prenom,mail,code_postal from Clients where code_postal = '58418'

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.

Il ne nous reste plus qu'à remplacer la requête dans le champ Requête de l'élément Requête JDBC par notre variable ${req_sql}.

Afin de vérifier que cela fonctionne, 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).

Voilà 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 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 :

other

    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êtes, on va noter ce qui peut être variabilisé.

Par exemple :

sql

    select nom, prenom from Clients where nom like 'D%'

deviendra :

other

    select {liste_selection} from {table} where {clause where}

Toutes ces variables seront dans un fichier CSV.

Extrait du fichier CSV :

other

    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 :

other

    select ${liste_selection_grp1} from ${table_grp1} where ${clause_where_grp1}

On fait la même chose pour le deuxième groupe de requêtes SQL.

Extrait du fichier CSV :

other

    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.

Avec encore un peu d'effort, on peut encore rendre plus réalistes les clauses WHERE de nos requêtes SQL.

On remarque que la clause WHERE peut être séparée en plusieurs parties.

other

    {clause where} = {clause where gauche} {clause where condition} {clause where droite}

Avec la même méthodologie que précédemment, on peut affiner notre fichier CSV et notre Requête JDBC pour 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 :

other

    liste_selection_grp1;table_grp1;clause_where_grp1 
    nom,prenom;Clients;nom like 'D%' 
    nom,prenom,mail,code_postal;Clients;code_postal = '58418'

Devient :

Extrait du fichier CSV :

other

    liste_selection_grp1;table_grp1;clause_where_gauche_grp1;clause_where_condition_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%'

Dans la majorité des cas, il y a des utilisateurs avec des droits de modification (appelons-les 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. On pourra ainsi 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ées juste avant par 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é.

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.

Comme on peut le voir, la requête récupère plusieurs identifiants.

On a le nombre de réponses dans la variable identifiant_client_#

On va choisir un identifiant au hasard dans la liste retournée. Pour cela on va utiliser la fonction __Random de JMeter.

La formule ${_Random(1,${identifiant_client#},identifiant_client_final)} mise dans un échantillon BeanShell nous permettra de réaliser ce que l'on veut en mettant l'identifiant dans la variable identifiant_client_final.

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.

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 :

other

    update Clients set telephone_fixe = ${num_tel} where id_client = ${identifiant_client_final}

Les administrateurs font aussi des requêtes SQL de type SELECT, et l'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.

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).

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.

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.

Maintenant, il suffit de remplacer dans le script les parties dupliquées par des Contrôleur Inclusion.

Les faire pointer sur notre script sauvegardé précédemment.

On aurait pu s'arrêter là 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 ».

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.

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.

other

    jmeter -n -l resultats.csv -t scenario.jmx -JnbUnites=10 -JrampUp=20 -JnbIterations=100

Notre plan de test enfin complet.

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.

Commençons par définir la 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 le chargement d'une sauvegarde, par la création de données à l'aide d'outils ou de commandes SQL, etc.).

Afin d'être sûr que les statistiques de notre base de données sont à 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 :

other

    begin 
    {call proçedure SQL} 
    end;

Dans notre cas, on aura :

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-

Notre base de données est prête.

On veut que notre test tourne tant qu'il y a des index à 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.

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.

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éponse plus précis.

Il suffit d'ajouter 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.

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 index sera directement récupérée à l'aide de la variable ${Create_Index_SQL} du fichier CSV défini précédemment.

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 seront récupérés à l'aide d'un élément Echantillon BeanShell associé à la fonction __counter.

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 :

other

    # 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 conclut notre script de test.

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.

Afin de générer un nouveau numéro de téléphone, utilisons l'élément Variable aléatoire :

Pour le nouveau nom, nous utiliserons un élément Echantillon BeanShell avec la fonction :

other

    ${__RandomString(20,ABCDEFGHIJKLMNOPQRSTUVWXTZabcdefghiklmnopqrstuvwxyz,nouveau_nom)}

Un nouveau nom de vingt caractères sera stocké dans la variable nouveau_nom :

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 :

Plusieurs lignes seront récupérées :

other

    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).

Comme on peut le voir, on ne peut boucler que sur une variable (ici on a choisi id_client), on perd donc 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 recré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…).

Puis, la fonction ${_V(xxx${yyy})} concaténera la chaîne de caractères 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.

Finalement, notre plan de test ressemblera à celui-ci.