Catégorie : Apache

JMeter : utilisation de l’élément JDBC comme source de données pour un test de charge (partie 1)

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 :

Nouvelle version d’Apache JMeter : 2.3.3

La nouvelle version de JMeter est sortie, passant de la 2.3.2 (sortie il y a un an) à la 2.3.3 (téléchargement). Un simple digit incrémenté, en troisième position, laissant penser qu’il s’agit d’une mise à jour mineure. Oui et non.

Oui, car il n’y a pas de révolution dans cette nouvelle version d’un point de vue fonctionnalité ou architecture interne. Non, car pour cette nouvelle version, la traduction en français de l’interface de JMeter a été revue, corrigée et complétée pour quasiment tous les éléments (à l’exception de JMS et LDAP étendu).

Dans la version précédente, la version française semblait être traduite par un traducteur automatique, il était souvent préférable d’utiliser JMeter dans la langue anglaise afin de bien comprendre les différents champs (et leurs fonctions) d’un élément. Il suffit de regarder les copies d’écrans sur les tutoriels de ce blog. Maintenant plus d’excuses pour ne pas l’utiliser en français, les termes ont été mieux choisi par rapport à leur signification dans le contexte.

Dans la liste des changements, il n’y a pas que la localisation (bien que l’on retrouve également l’ajout du polonais et du portugais (du Brésil)).

Parmi les évolutions ont trouve :

Continuer la lecture de Nouvelle version d’Apache JMeter : 2.3.3

JMeter : utiliser SQLite pour traiter les résultats d’un test de charges par palier

Dans ce billet, j’indique qu’il est possible d’utiliser SQLite pour traiter les données d’un tir de charges par palier (tutoriel ici).

Voici maintenant le mode d’emploi pour utiliser SQLite afin de traiter ses résultats de tir JMeter. Continuer la lecture de JMeter : utiliser SQLite pour traiter les résultats d’un test de charges par palier

JMeter et la création du rapport de tir de charges

Après l’exécution d’un tir de charges, il faut faire le rapport de tir avec si possible de beaux tableaux et/ou graphiques. Si vous avez déjà utilisé JMeter (ce que je présuppose) vous savez que les récepteurs de JMeter sont bien pour avoir des tableaux de résultats (en particulier celui du rapport consolidé), mais ils montrent des limites pour faire des tableaux personnalisés ou bien de beaux graphiques « parlants ».

Il se pose aussi la problématique de l’insertion des résultats affichés par les récepteurs de JMeter dans le document Word ou la présentation PowerPoint (ou OpenOffice). La capture d’écran fait un peu trop ‘bricolage’.

En général, il est préférable de récupérer les résultats au format CSV, puis de les traiter dans un tableur comme Excel ou Calc pour faire des tableaux et des graphiques (voir ce tutoriel).

Mais là aussi, on trouve des limites, notamment pour les « gros » tests de charges avec plus de 100 000 lignes de résultats. Les graphiques étant limités à 32 000 points (Excel/Calc) et les feuilles de tableur à 65 000 lignes (Calc / Excel 2000/2003) et 1 million (Excel 2007).

Une solution possible est de développer un programme « moulinette » qui va effectuer un premier traitement sur les données CSV pour réduire ou agréger les données, par exemple en calculant le temps moyen par intervalle de temps (i.e. par minute, par heure, etc.).

Une autre solution est d’utiliser un logiciel de base de données bureautiques comme Access ou Base pour gérer le grand nombre de lignes, voir cet article.

Une autre solution, que je trouve ‘sympa’, pratique et finalement assez simple pour un informaticien, c’est d’utiliser la petite base de données SQLite. Continuer la lecture de JMeter et la création du rapport de tir de charges

JMeter : Utiliser le compteur de débit constant

Dans ce précédent billet, je montrais une façon de fixer l’intervalle de répétition de ses requêtes, c’est-à-dire lancer une requête chaque 10 secondes quelque soit le temps de réponse de la requête.

JMeter permet faire cela « nativement » avec l’élément Compteur de débit constant.

Voici un arbre JMeter mettant en œuvre cet élément :

Continuer la lecture de JMeter : Utiliser le compteur de débit constant

JMeter : authentification par certificat SSL avec JMeter en mode non-gui

Un billet rapide pour compléter ce premier billet, et pour répondre à la question « comment tester un site demandant l’authentification par certificat SSL tout en lançant JMeter en ligne de commande ? ».

Pour cela, rien de sorcier, on édite le fichier Jmeter_Home/bin/system.properties.

Au niveau des lignes :
===================
# Location of the keystore
javax.net.ssl.keyStore=/home/milamber/client-ssl-authentification.p12
#
#The password to your keystore
javax.net.ssl.keyStorePassword=Mon_Password_P12
===================

Ensuite, on peux lancer JMeter en ligne de commande normalement.

Accessoirement, il n’est plus nécessaire de choisir le P12 dans JMeter en mode graphique (pour ce site).

Plus d’infos (en anglais) : le composant SSL Manager dans la documentation JMeter.

./

JMeter : faire un test distribué avec des injecteurs à deux cartes réseaux

Suite à une discussion avec Eudes (merci) sur le groupe JMeter en français, voici une architecture possible (et testée) pour un test distribué avec des injecteurs qui possèdent deux cartes réseaux.

Une carte réseaux est tournée vers le contrôleur, et une autre carte réseaux est tournée vers le serveur à tester. L’avantage de ne pas mélanger les trafics réseaux : celui des requêtes (vers le serveur) et celui de résultats du test (vers le contrôleur).

Donc voici la recette : Continuer la lecture de JMeter : faire un test distribué avec des injecteurs à deux cartes réseaux

JMeter : Exemple de script BeanShell pour enregistrer des données dans un fichier

Un petit billet dans un but pédagogique, pour montrer un exemple de script BeanShell pour enregistrer des données dans un fichier texte.

Soit le plan de test suivant :

Dans ce plan de test, on extrait avec l’extracteur d’expressions régulières des données de la page reçue, (ici un NOMBRE).

On ajoute ‘au passage’ une assertion de réponse qui est là pour s’assurer que l’expression regexp a réussie (on vérifier si on (re)trouve le NOMBRE précédemment cherché dans la page).

Et pour finir, on a un élément post-processeur BeanShell qui exécuter un bout de code Java pour faire l’enregistrement de la variable NOMBRE dans un fichier.

Continuer la lecture de JMeter : Exemple de script BeanShell pour enregistrer des données dans un fichier

JMeter : Trouver le bon élément dans une liste avec les expressions régulières et en mode ligne unique

Voici un billet pour parler des expressions régulières (regexp) avec JMeter. L’élément Extracteur d’expressions régulières est très utile dans les scénario JMeter pour extraire des données de la réponse reçues suite à une requête. Par contre, il n’est pas toujours facile d’avoir (de trouver) la bonne regexp…

J’ai mis quelques heures pour trouver cette regexp qui était nécessaire pour la préparation d’un scénario de test de charges JMeter. J’ai même adapté un petit programme Java/Swing testeur de regexp style Java pour qu’il devienne un programme testeur de regexp Jakarta ORO, celui du JMeter, ceci afin de tester plus vite les différentes regexp.

Commençons, soit le texte de réponse d’une requête HTTP (utilisant en fait SOAP/XML-RPC) suivant :

<ClientBean>
<id>765432</id>
<code>1.87665308</code>
<nom>JAMES BOND</nom>
<statutNumAppel>Inactif</statutNumAppel>
</ClientBean>
<ClientBean>
<id>765432</id>
<code>1.33333333</code>
<nom>LARGO WINCH</nom>
<statutNumAppel>Inactif</statutNumAppel>
</ClientBean>
<ClientBean>
<id>765432</id>
<code>1.87999999</code>
<nom>BENGAMIN GATES</nom>
<statutNumAppel>Actif</statutNumAppel>
</ClientBean>
<ClientBean>
<id>765432</id>
<code>1.23334444</code>
<nom>EMMA PEAL</nom>
<statutNumAppel>Inactif</statutNumAppel>
</ClientBean>

Cette liste est dynamique (on n’a pas toujours 4 éléments, celui ayant le statut d’actif n’est pas toujours à cette position (ici 3ème) et les valeurs bien entendues changent pour chaque requête du test).

Comment faire pour extraire le code « 1.87999999 » correspondant au même ID 765432 pour chaque élément de cette liste, et qui est celui « Actif » ? Le tout avec une expression régulière JMeter ? Continuer la lecture de JMeter : Trouver le bon élément dans une liste avec les expressions régulières et en mode ligne unique

JMeter : Think time et ordre d’exécution, « les bons plans »

Un billet inspiré d’une discussion sur le groupe Google JMeter en français (merci Jslave).

Vous avez fait ce plan de test, avec 2 itérations dans la boucle (01 Contrôleur Boucle) :

En pensant avoir l’ordre d’exécution suivant (pour un groupe d’unités à 1-1-1) :

  • 01 Requête Login
    • (1ère itération de boucle)
      • (Compteur de temps fixe : pause 2 sec)
      • 02 Requête A
      • (Compteur de temps fixe : pause 2 sec)
      • 02 Requête B
      • (Compteur de temps fixe : pause 2 sec)
      • 02 Requête C
    • (2ème itération de boucle)
      • (Compteur de temps fixe : pause 2 sec)
      • 02 Requête A
      • (Compteur de temps fixe : pause 2 sec)
      • 02 Requête B
      • (Compteur de temps fixe : pause 2 sec)
      • 02 Requête C
  • 02 Requête Logout

Malheureusement, le plan de test n’aura pas cet ordre d’exécution Continuer la lecture de JMeter : Think time et ordre d’exécution, « les bons plans »