Je viens d’effectuer une mise à jour du tutoriel JMeter sur la réalisation d’un test de charge distribué.
Il s’agissait principalement de mettre des captures d’écrans d’un JMeter « français », d’adapter le texte associé, mais également de corriger des fautes de style ou d’orthographes…
On notera que depuis 2008, la date d’écriture de la première version de ce tutoriel, il n’y a pas eu de changement au niveau JMeter sur la configuration d’un test distribué.
./
Dans la continuité du billet précédent, si vous avez besoin de faire une assertion sur un fichier Word, Excel ou Powerpoint, voici la méthode toute simple avec l’API Apache POI.
Si jamais vous avez besoin de faire une vérification sur le contenu d’un fichier PDF lors d’un test de charge (ou fonctionnel), voici un excellent petit billet qui vous donne la solution.
Pour cela, l’auteur utilise l’API PDFBox de Apache dans un petit BeanShell pour extraire le texte du PDF, puis faire une assertion dessus.
Avec Tomcat ou Jboss, il est possible d’enregistrer le temps de traitement d’une requête HTTP. Il y a en effet une valve AccessLogValve (désactivée par défaut) qui trace les accès (requêtes) HTTP qui sont effectués sur le serveur. Avec une petite modification du format du log, on peut ajouter l’enregistrement du temps de traitement coté Tomcat ou Jboss de la requête.
Ceci est particulièrement utile pour décorréler le temps de traitement par rapport au temps de réponse enregistré dans un outil de test de charge, comme JMeter.
Voici comme faire dans Tomcat :
Au niveau du fichier Tomcat_Home/conf/server.xml, on trouve la section suivante en commentaires :
<!-- <Valve className="org.apache.catalina.valves.AccessLogValve" directory="logs" prefix="localhost_access_log." suffix=".txt" pattern="common" resolveHosts="false"/> --->
Continuer la lecture de Tomcat ou Jboss, enregistrer le temps de traitement des requêtes HTTP
Aucun billet depuis le début de cette nouvelle année, je dois quelques nouvelles à ce blog.
Tout d’abord, j’ai eu un changement d’activité professionnelle en ce début d’année, qui m’accapare beaucoup de temps. Cela devrait se tasser et me permettre d’ajouter quelques billets sur JMeter.
Ensuite, car je travaille « in deep » dans JMeter, je suis en effet entrain d’essayer d’y ajouter un contrôleur « parallèle » pour permettre l’exécution en parallèle de requêtes HTTP pour un même utilisateur virtuel.
Ceci permettra de mieux simuler certains sites web 2.0 qui ont beaucoup de requêtes AJAX, ces dernières utilisant à bon escient les flux parallèles possibles dans un navigateur internet moderne (exemple, Firefox 3.5 c’est 6 flux parallèles). L’idée étant d’avoir un temps de réponses « écran web 2.0 » proche de celui du navigateur. En effet, aujourd’hui avec JMeter, si j’ai un écran d’un site web 2.0 ayant 10 requêtes (1 principale et 9 requêtes ‘ajax’), JMeter fera 10 requêtes en série, et donne donc un temps différent et généralement plus important que le navigateur qui lui, envoie ses 10 requêtes sur 2 à 6 flux parallèles. On peut voir ce phénomène sur Firefox avec le plugin Firebug ainsi qu’au niveau du paramètre network.http.max-persistent-connections-per-server dans Firefox > about:config.
C’est un travail difficile de développement, car la conception applicative de JMeter est « historique » (depuis 1998), et parfois empirique. La gestion des unités d’exécution s’effectuant en 1 thread = 1 VU, avec un ensemble de services disponibles par thread à un niveau élevée (très loin de la requête HTTP). Pour faire des flux parallèles, j’ai besoin de ces services à un niveau très bas (proche de la requête HTTP), et là c’est difficile.
Enfin, je pense avoir réussi à trouver une solution, j’ai maintenant un contrôleur qui sait balancer n flux parallèles, maintenant il faut faire un (gros) travail sur la préservation de l’intégrité des données partagées entre les flux parallèles…
J’espère que je vais réussir complètement à faire ceci.
Ah, j’allais oublier ! Très bonne année 2010 !
./
Voici un billet pour parler de l’extracteur d’expressions régulières dans JMeter.
Commençons par le plan de test : très simple, une requête avec en élément fils un extracteur d’expression régulière.
La requête HTTP est simplement la page d’accueil de ce blog.
On place un échantillon Débogage après la requête HTTP qui possède l’extracteur d’expression régulière, il permet d’afficher différentes informations internes à JMeter. Ici, on s’intéresse aux valeurs des variables de JMeter.
Ensuite (enfin) vient l’extracteur d’expression régulière, on commence par un « simple ».
Quelques explications : Continuer la lecture de Quelques cas d’utilisation de l’extracteur d’expression régulière dans JMeter
[Article mis à jour le 08 décembre 2011, pour prise en compte de la version 2.5.1]
Depuis la version 2.4 de JMeter, une nouvelle fonctionnalité permet le changement d’adresse IP source pour les requêtes HTTP transmises par JMeter.
L’intérêt de cette possibilité est (par exemple) de permettre de faire des tests de charges sur des architectures techniques comportant un suivi de session par adresse IP (typiquement au niveau des répartiteurs de charges).
Voici un petit mode d’emploi. Continuer la lecture de Changer l’adresse IP source d’une requête HTTP lors d’un test avec JMeter
La première version de JMeter, estampillée 1.0, date du 15 décembre 1998. Ensuite l’année 1999 va voir au moins 4 versions successives de JMeter.
Aujourd’hui, près de 11 ans après, il y a eu environ 20 versions ‘majeures’ de JMeter, et nous en sommes à la version 2.3.4.
Voici un petit retour-arrière sur les différentes interfaces graphiques de JMeter depuis la première version jusqu’à la dernière.
Et voici la première version 1.0.2, on remarquera la simplicité de l’interface : un seul écran, un bouton Start, un Stop. Seulement 10 unités d’exécution maximum. On reconnaît le récepteur de résultat graphique que l’on retrouve encore dans les versions d’aujourd’hui.
Continuer la lecture de Retour dans le passé, voici les différentes versions de JMeter
Voici un petit billet pour vous monter comment lancer JMeter en ligne de commande tout en paramétrant son scénario de test.
En effet, vous pouvez avoir l’idée ou l’envie de faire une série de test en jouant sur certains paramètres de votre scénario JMeter, le tout en ligne de commande. Par exemple, faire un test avec 1 utilisateur, puis le même test avec 10 utilisateurs, et le même avec 100 utilisateurs.
Bien évidemment vous pouvez les lancer depuis l’interface graphique de JMeter, à la suite, tout en modifiant le paramètre du nombre d’utilisateurs dans l’interface, mais c’est trop facile ;-).
Donc pour le faire en ligne de commande, il faut d’abord passer par l’interface graphique JMeter. En effet, nous avons besoin d’utiliser une fonction JMeter qui va permettre de lire une propriété JMeter et renvoyer sa valeur. Cette fonction doit être appelée à la place de la valeur du champ correspondant au paramètre que l’on veut rendre « paramétrable »…
Le mieux est d’abord de voir la capture d’écran :
Les différents ${__P(xxx,yyy)} correspondent à notre fonction JMeter qui permet de lire une propriété JMeter, et qui la renvoie. Continuer la lecture de Envoyer en ligne de commande des paramètres à votre scénario JMeter
La prochaine version de Ubuntu sera la 9.10 (Karmi Kaola), elle est actuellement en bêta. Il va y avoir des nouveautés, mais celle qui me tiens à cœur, c’est JMeter sera disponible dans ses paquetages.
D’après ce que je comprends, c’est la récupération du paquetage JMeter de la distribution Linux Debian (dont Ubuntu est un dérivé).
C’est une bonne chose, pas parce que cela simplifie ou non son installation, cette dernière étant assez simple (une JVM + la décompression du fichier zip JMeter), mais cela me donne le sentiment d’une certaine reconnaissance de l’outil.
C’est la version 2.3.4 (la dernière en date) qui est distribuée. Pour effectuer son installation à partir de la version bêta de Ubuntu 9.10, il suffit de taper la commande suivante :
sudo apt-get install jmeter
Cela installera 3 paquetages (jmeter, jmeter-help, jmeter-http) de base (et leur dépendances). Avec cela, vous pouvez faire des tests de charges sur des sites Web.
Pour faire des tests sur LDAP, FTP, JMS, Junit, Mail, TCP et Java, il faudra ajouter le paquetage correspondant. Voir ce lien pour la liste des paquetages disponibles.
Bons tests.