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.

./