Ce tutoriel a pour objectifs :

1. Rappeler l’utilisation de Requête JDBC pour accéder à une base de données, et récupérer dans un ensemble de variables les résultats de requête JDBC
2. Montrer comment effectuer l’ajout d’une fiche Utilisateur dans un serveur LDAP via une Requête LDAP étendue de JMeter
3. Montrer le fonctionnement du Contrôleur Pour chaque dans JMeter
4. Montrer un petit exemple de Pré-Processeur BeanShell

Voici le plan de de test final.

On observe deux sections :

1. Base de données : qui est un Contrôleur Simple regroupant les éléments nécessaires à la partie JDBC afin d’accéder à la base et faire la requête SQL qui va permettre de récupérer les utilisateurs à créer.
2. LDAP : qui est aussi un Contrôleur Simple regroupant les éléments permettant la connexion au serveur LDAP et effectuer la requête d’ajout dans le LDAP des utilisateurs.

Concernant la partie Base de données, je vous revois vers ce billet pour avoir plus de détails sur sa mise en place. Ci-dessous, je vais seulement commenter certains éléments de cette partie.

L’élément Requête JDBC correspond à la requête SQL que JMeter va effectuer pour obtenir une liste de noms et de prénoms qui seront utilisés dans la section LDAP.

• Le champ Nom de liaison fait référence au ‘pool’ JDBC configuré dans l’élément Configuration de connexion JDBC
• Le type de requête est Select Statement, on fait donc une requête SQL commençant par SELECT :
  • SELECT ID, NOM, PRENOM from BOXERS
• Dans le champ Noms des variables, on donne les variables (JMeter) qui vont recevoir les données. Pour nous, cela sera VAR_ID, VAR_NOM, VAR_PRENOM.

A l’exécution, la requête SQL retournera une liste de noms et les placera dans les variables correspondantes, avec un suffixe _X où X est le numéro de la ligne retournée.

Pour la section suivante, LDAP, on utilisera donc ces variables pour faire l’ajout dans le LDAP.

Ainsi voici la partie LDAP : le premier élément est une Requête LDAP étendue qui va permettre de faire la connexion avec le serveur LDAP.

Pour cela, on choisi le type de test « Unité liée », et on complète les différents champs nécessaires :

• Nom du serveur (ou adresse IP)
• Port : 389 (correspondant au port par défaut pour le protocole ldap)
• DN : nom du suffixe de l’annuaire
• Identifiant : un compte disposant des droits pour modifier l’annuaire (ici c’est l’administrateur LDAP)
• Mot de passe associé au compte ci-dessus
• Délai d’attente de connexion : paramètre optionnel qui permet de faire échouer l’échantillon (de connexion) si jamais la connexion n’est pas ouverte
• La case à cocher permet de faire une connexion via le protocole LDAPS (via SSL donc) (accompagné par le port 636 en général)

Ensuite, on en profite pour faire l’opération inverse de la connexion : la Déconnexion. Pour cela, on choisit tout simplement le type de test « Délier les unités ». Cette requête sera placée en fin du scénario.

Passons aux éléments qui vont nous permettre d’ajouter les fiches annuaires dans le LDAP.

Le contrôleur ci-dessus, Pour chaque va tout simplement (efficacement je dirais), parcourir une à une les variables VAR_NOM_x où x est le numéro de ligne des résultats de la requête SQL précédente. À chaque itération, il va affecter à la variable NOM la valeur de VAR_NOM_x. (on notera la correspondance entre VAR_NOM de la requête JDBC Select et le VAR_NOM_x du contrôleur)

Ici, on ajoute un Compteur JMeter qui nous permet de connaître (suivre) le numéro de ligne, afin que nous puissions l’utiliser dans la prochaine requête pour générer des variables.

Nous voilà dans la requête « costaude », il s’agit d’une Requête LDAP étendue qui va traiter l’ajout. Ainsi, on choisit le type de test « Add test ».

Puis le champ Entry DN nous permet d’indiquer l’identifiant unique de la fiche dans l’annuaire.

Le tableau suivant, permet d’ajouter les couples « clé: valeur » suivant le principe du fichier LDIF (importation de comptes LDAP).

On notera les points suivants :

• ${__V(VAR_PRENOM_${CPT})} permet de générer la variable « ${VAR_PRENOM_x} pour chaque itération du Contrôleur Pour chaque
• ${NEW_NOM} et ${NEW_PRENOM} sont des variables définies dans un Pré-processeur BeanShell (ci-dessous)

Dans la requête d’ajout, il est important de ne pas oublier les éléments « objectclass » qui vont définir la structure de la fiche annuaire.

En fils de la requête d’ajout, on place donc un Pré-processeur BeanShell, qui va permettre d’effectuer quelques actions (ou préparations) sur les données avant leur utilisation.

Tout d’abord, on récupère la variable CPT (via vars.get( »GET »)), puis avec une concaténation, on récupére la valeur de la variable VAR_PRENOM_x. On supprime les points et enlève les guillemets (car certains noms dans la base des boxers ont des pseudonymes entre guillemets). Puis on refait la même chose avec le NOM.

Pour finir, on génère l’adresse email via un petit passage en minuscule et une concaténation du domaine de messagerie.

A chaque fois, on utilise le vars.put pour déposer des nouvelles variables dans JMeter.

Ensuite, avec l’élément suivant, une Assertion Réponse, j’anticipe sur l’exécution et la vérification que tout s’est bien passé. En effet, si l’exécution de la requête d’ajout LDAP fonctionne correctement, le résultat contient « <responsemessage>Success</responsemessage> ». L’assertion sur ce texte va nous permettre de détecter rapidement les cas en erreur (si il y en a).

Après la requête d’ajout, on place une requête de recherche dans le LDAP (type de test : Search test). C’est optionnel, c’est juste pour faire une seconde vérification du bon ajout.

On notera :

• Le champ Search Filter qui est ici le « uid » inséré
• Le champ Scope est positionné à Effectuer une recherche ‘onelevel’ (on ne recherche pas dans les sous-éléments de l’arbre LDAP)
• Le champ Size limit pour limiter à 1 le résultat retourné (on fait une recherche unitaire)
• Le champ Limite de temps à 10000 (ms) pour faire échouer l’échantillon si le serveur LDAP est trop long à répondre
• Le champ Attributes (optionnel) qui permet de choisir les champs à récupérer, ici le CN, SN et Mail
• Et pour finir, la case à cocher Examiner les résultats de recherche ? va permettre d’avoir dans les résultats du test, les valeurs des champs récupérés afin notamment de faire (par exemple) une assertion.

Ensuite (enfin) on peut passer à l’exécution du scénario JMeter.

Pour cela, on grade la configuration par défaut du Groupes d’unités, à savoir : 1 unité qui monte en charge en 1 seconde et qui faire 1 itération (1-1-1).

(c’est le Contrôleur Pour chaque qui se charge des itérations sur les utilisateurs)

Voici l’arbre de résultats :

Si tout s’est bien passé, tout est vert. Dans les données de réponses, on voit les résultats des requêtes LDAP, avec la valeur Success.

On peut également vérifier dans les données de réponses que par exemple la génération des adresses email s’est bien déroulée.

Un récepteur Résultats d’assertion, configuré pour afficher uniquement les erreurs, permet de voir les utilisateurs qui ont eu un problème lors de l’exécution. Ici, il y a eu des soucis visiblement sur les noms de boxers qui ont un caractère accentué…

Et voilà, avec ce tutoriel, on découvre que JMeter sait faire d’autre chose qu’un test de charge Web.

Vous noterez que ce type de scénario, fait de JMeter une sorte d’ETL (Extract-Transform-Load). Ainsi, on peut même imaginer d’adapter ce scénario pour maintenir une synchronisation entre une base de données et un LDAP, le tout en exécutant JMeter en mode non-gui dans une tâche programmée ou un cron.

Je prépare une suite à ce tutoriel concernant la conversion automatisée des mots de passe stockés ici en clair dans le LDAP, vers des mots de passe stockés en SHA-1.

Bons scénarios.

En annexes :
A/ Un petit SELECT de ma base de données (histoire de montrer sa structure)

mysql> select * from BOXERS limit 10;
 +----+----------+------------+
 | ID | PRENOM   | NOM        |
 +----+----------+------------+
 |  1 | Muhammad | Ali        |
 |  2 | Lou      | Ambers     |
 |  3 | Vito     | Antuofermo |
 |  4 | Jorge    | Arce       |
 |  5 | Alexis   | Arguello   |
 |  6 | Henry    | Armstrong  |
 |  7 | Abe      | Attell     |
 |  8 | Monte    | Attell     |
 |  9 | Yuri     | Arbachakov |
 | 10 | Satoshi  | Aragaki    |
 +----+----------+------------+
 10 rows in set (0.03 sec)

B/ Le format LDIF d’exemple (qui permet de connaître les champs à ajouter dans la requête LDAP d’ajout, mais entendu, il faut l’adapter pour que cela colle avec le vôtre (serveur LDAP))

dn: uid=milamber,ou=Users,dc=milamberspace,dc=net
objectclass: organizationalPerson
objectclass: person
objectclass: top
objectclass: inetOrgPerson
uid: milamber
userPassword: jmeter2009
cn: milamber
mail: milamber@milamberspace.net
displayname: Milamber
givenname: Milamber
sn: Milamber

./

Le schéma ci-dessous montre les deux parties. Dans les lignes suivantes, on s’occupera donc de la deuxième partie.

Tout d’abord, la deuxième partie débute par un Contrôleur Simple, puis on attache directement un élément de configuration Paramètres HTTP par défaut dans lequel on configure l’adresse du serveur à tester. Pour moi, cela sera un simple serveur Tomcat avec ses applications d’exemples. Ce tutoriel détaille le scénario fonctionnel.

Ensuite vient un élément de configuration Compteur, que l’on initialise (Lancer) à 1 avec un incrément de 1. Son nom de référence sera CPT.

La requête HTTP arrive ensuite. Il y a bien entendu l’URL à appeler, mais également les paramètres à envoyer dans ce formulaire pour avoir le Prénom et Nom en résultat.

C’est ici, que nous allons utiliser les variables récupérées du billet précédent. Pour cela nous allons utiliser une fonction JMeter bien pratique puisqu’elle va évaluer une chaîne de caractères générée en tant que nom de variable. La fonction est __V() (deux soulignés et V)

Nous avons ainsi :

${__V(VAR_PRENOM_${CPT})}

qui va faire pour un CPT à 1, le nom de variable VAR_PRENOM_1 (et compris comme ${VAR_PRENOM_1})

Et comme le compteur va s’incrémenter de 1 à chaque itération, nous allons avoir ${VAR_PRENOM_1}, ${VAR_PRENOM_2}, ${VAR_PRENOM_3}, etc.

En élément fils que la requête HTTP, on peut placer de manière optionnelle, une Assertion Réponse qui vient vérifier que l’envoi du formulaire a bien fonctionné (car l’application affiche le nom et prénom qui ont été envoyés).

Il ne reste plus qu’a faire une exécution (en gardant le paramétrage en 1-1-10 du groupe d’unités)

Voici les résultats dans l’élément Arbre de résultats :

Génial, cela marche ! (vous en doutiez ? )

Ah mais que ce passe-t-il à partir de la septième itération ?

L’explication est simple, ma requête SQL ne renvoie que 6 éléments, donc JMeter ne trouvant plus d’éléments, envoi le nom de la variable… Allez, c’est facile à régler, il suffit de mettre dans le champ Maximum du Compteur CPT, la variable suivante : ${VAR_ID_#} qui, je vous le rappelle, correspond au nombre d’éléments retournés pour le champ VAR_ID. Donc ici pour nous c’est 6.

Ainsi lors de l’exécution, le compteur va re-boucler de 1 à 6 (min à max) indéfiniment.

Et voilà, vous avez donc maintenant un script JMeter qui attaque une table dans une base de données pour ensuite faire un test de charges avec ces données.

Une petite remarque pour la fin :

Si jamais vous voulez utiliser un plan de test similaire à celui du tutoriel pour un test de charge avec 1 million de lignes remontées par la requête SQL, il y a de forte chance pour qu’il y ait des problèmes de mémoire dans votre JMeter, car cela va faire 1 million de variables en mémoire (ouille!)

./

]]> http://blog.milamberspace.net/index.php/2009/06/13/jmeter-utilisation-de-lelement-jdbc-comme-source-de-donnees-pour-un-test-de-charge-partie-2-317.html/feed 0 http://blog.milamberspace.net/index.php/2009/06/12/jmeter-utilisation-de-lelement-jdbc-comme-source-de-donnees-pour-un-test-de-charge-partie-1-311.html http://blog.milamberspace.net/index.php/2009/06/12/jmeter-utilisation-de-lelement-jdbc-comme-source-de-donnees-pour-un-test-de-charge-partie-1-311.html#comments Fri, 12 Jun 2009 22:44:11 +0000 Milamber http://blog.milamberspace.net/?p=311 Avec la version 2.3.3, JMeter nous propose une amélioration de l’échantillon JDBC, qui permet de récupérer les valeurs de champs d’une requête SQL de type SELECT et de les placer dans des variables JMeter.

D’où l’idée suivante : Pourquoi ne pas utiliser une base de données comme source de données pour un test de charge ?

Tout d’abord les pré-requis :

• Une base de données bien entendu, avec le pilote JDBC approprié, à placer dans Jmeter_Home/lib
• Dans la base de données, une table avec une liste d’éléments (ici j’ai repris mon fichier BOXERS que j’ai inséré en base)

Bon voyons un peu comment faire. Ci-dessous le plan de test à mettre en œuvre :

Il y a deux parties :

• Partie 1 : qui est chargée de récupérer les données de la base de données (objet de ce billet)
• Partie 2 : qui est le test de charge à proprement parlé, et qui est donc chargé de consommer les données (objet du billet suivant)

Dans la partie 1, tout d’abord, on place un Contrôleur Exécution unique, il va permettre d’exécuter une unique fois la requête SQL de sélection de la liste de données qui va servir au test. Les itérations suivantes ne ré-exécuteront pas la requête.

Juste dessous, en tant que fils, on trouve l’élément Configuration de connexion JDBC, c’est avec lui que nous allons pouvoir définir le pool de connexions vers la base de données.

Ci-dessous, sa configuration :

Ici, on définit un pool avec un nom de liaison jdbc/pool qui sera utilisé plus tard. C’est une base de données MySQL, comme vous le constatez dans la partie configuration de connexion à la base de données.

Je ne détaille pas, je suppose que vous avez déjà configuré un pool sur un serveur de type Tomcat ou autre (voir google sinon)

On notera que la requête de validation permet de vérifier la connexion avant que le pool ne donne la connexion à la requête (échantillon JDBC). Ici dans ma base « milambertestdb » il y a une table vide « POOL_HEARTBEAT ».

Une fois que le pool est défini, on peut passer à la requête JDBC. Ci-dessous sa configuration :

• Le nom de liaison : jdbc/pool en référence bien sur à l’élément de configuration JDBC
• Le type de requête est placé à « Select Statement » afin de permettre d’effectuer une requête SQL de type SELECT
• La requête (SQL) suivante est indiquée :
  • select ID, NOM, PRENOM from BOXERS where UTILISABLE = 1 AND PRENOM LIKE ‘Ar%’
  • On sélectionne dans la table BOXERS, trois champs (ID, NOM, PRENOM) à condition que le champ UTILISABLE soit égale à 1 et que le prénom commence par « Ar ».
• Les champs Valeurs des paramètres et Types des paramètres ne sont pas utilisés car nous n’avons pas d’éléments variables à insérer dans la requête SQL pour son exécution.
• Le dernier champ Noms des variables est, par contre, utilisé pour définir les préfixes de variables JMeter qui seront utilisées pour stocker les valeurs résultants de la requête SQL.

Ensuite, juste après la requête JDBC, on place un échantillon Débogage à des fins de… débogage , ainsi on pourra voir si tout se passe bien du coté des Variables JMeter durant le tir.

Ensuite on place en fils du contrôleur Exécution unique, un récepteur Arbre de résultats, et on lance un itération de test (le Groupe d’unités est configuré à 1-1-10).

Voici le résultat d’exécution :

Dans la requête SQL, au niveau de l’onglet Données de réponse, on trouve un tableau contenant la liste (ici de six éléments) de réponse.

Au niveau de l’échantillon Débogage, on trouve trois ensemble de variables correspondant aux données de la liste.

Chaque ensemble est définit par :

• une variable « Nom_De_Champ + _# » pour donner le nombre d’éléments retournés
• N variables « Nom_De_Champ + N » pour chaque valeur retournée

Dans la partie suivante, nous allons voir comment utiliser ces données pour faire son test.

Mine de rien, vous venez de faire un script qui attaque une base de données, et cela peut vous servir dans d’autres cas, notamment tester les performances d’une base de données.

./