MilamberSpace – JMeter

Ce billet est un petit « howto » pour vous montrer comment utiliser JMeter pour envoyer un email (courriel), ici en utilisant le serveur de messagerie SMTP de Google Mail.

Pour rappel, le SMTP (Simple Message Transfer Protocol) est le protocole normalisé d’échange de message électronique (email). Dans JMeter depuis la version 2.4, un nouvel échantillon appelé Requête SMTP a été ajouté pour avoir un client SMTP qui envoi donc un email.

Bien entendu, JMeter étant un outil de test de charge, avec cet échantillon, on peut faire un test de charge sur un serveur de messagerie franchement installé pour vérifier sa tenue de charge et robustesse (ce qui est mon cas), on peut aussi utiliser cet échantillon SMTP pour par exemple s’envoyer un email de rapport à la fin d’un test de charge « long » (qui dure plusieurs heures ou jours), ou tout simplement dans le cadre de la mise en place d’un système d’alerte en cas de temps de réponse dégradé d’un site web (par exemple) avec un script qui s’exécute toutes les x minutes ou heures.

Revenons à notre sujet, voici notre arbre JMeter tout simple pour ce test :

Continue reading ‘Envoyer un email avec JMeter via son élément Requête SMTP’ »

Antonio Gomes Rodrigues nous livre deux tutoriels sur la réalisation de plan de tests de charge :

• Créer des plans de tests de charge réalistes
• Développer un plan de test avec JMeter

Par le passé, il avait déjà publié un autre tutoriel sur l’audit de performances d’une application en Java EE.

Hudson est une plate-forme d’intégration continue, JMeter est un outil de test de charge et aussi de tests fonctionnels (on a tendance à l’oublier, mais pour faire du test de charge, il faut savoir faire du test fonctionnel). Que diriez vous d’intégrer dans Hudson l’exécution d’un test (de charge) JMeter, et d’avoir un beau graphique pour voir l’évolution des temps de réponses de votre application en fonction des ‘builds’ Hudson / versions de votre application ?

La réponse à cette question est l’objet de ce tutoriel. Continue reading ‘Intégration d’un test JMeter dans Hudson avec le plugin Hudson Performance’ »

Maintenant que nous avons vu comment faire des scripts Groovy dans JMeter, utilisons Groovy pour faire des requêtes HTTP parallèles avec JMeter.

Oh ! Des requêtes parallèles !? Le vieux rêve dans JMeter… certainement l’une des premières questions que j’ai posé sur la mailing-list des utilisateurs JMeter (jmeter-user).

Bon, je vous préviens, il ne s’agit pas encore de faire un méga test de charge avec ce genre de requêtes parallèles, mais cela peut aider pour des tests ayant des besoins de lancement simultané de requêtes, ou toute autre idée qui vous vient à l’esprit.

Le premier pré-requis est donc d’avoir un JMeter prêt pour faire du Groovy.

Ensuite, nous allons utiliser HTTPBuilder, qui est une couche API basée sur Apache HttpClient, et accessible en Groovy. HTTPBuilder sait faire pas mal de choses (comme du parsing automatique de requêtes JSON), etc. Ici, nous allons dans ce billet seulement nous intéresser à sa capacité à faire des requêtes HTTP de manière asynchrone.

Le petit nom de ce type de requête dans HTTPBuilder est AsyncHTTPBuilder. C’est une requête HTTP qui, au lieu d’être exécutée en premier plan, est envoyée en arrière-plan via une exécution dans un pool d’exécution (élément Executor dans l’API Java) et l’utilisation d’un type particulier : java.util.concurrent.Future pour le résultat de l’exécution de la requête. Ce ‘future’ permet d’avoir la possibilité de lancer plusieurs requêtes HTTP asynchrones (quasiment en même temps), puis de récolter le résultat de leurs exécutions ensuite. Continue reading ‘JMeter et Groovy : avoir des requêtes HTTP concurrentes’ »

Même si cela ne se voit pas trop, je suis relativement imprégné de JMeter, en effet, j’ai développé un nouveau récepteur graphique pour voir sous forme de graphique ses résultats d’une manière plus parlante que les récepteurs graphiques existants nativement sous JMeter, mais malheureusement des problèmes de compatibilité de licence Apache licence vs LGPL ne permettent pas de committer directement ce travail dans JMeter (je sais, j’aurais dû faire attention…). Toujours est-il que je dois maintenant externaliser ce récepteur sous forme d’extensions. Je vais certainement le proposer sur apache-extras, un lieu de stockage de projets liés à la fondation Apache.

Néanmoins il ne faut pas attendre ce nouveau récepteur pour avoir des récepteurs graphiques jolis car il existe des récepteurs dans l’extension jmeter-plugins, qui permettent d’avoir une belle représentation graphique (entre autres) de ses résultats. C’est excitant à tester, les différents graphiques sont d’une aide précieuse pour l’analyse d’un tir. Continue reading ‘Quelques nouvelles. JMeter, jmeter-plugins, Debian 6.0, Nokia N8’ »

JMeter dispose de plusieurs éléments « BSF » pour Bean Scripting Framework. Ce cadre de travail (framework), fait par la Fondation Apache, permet de faire un pont entre le Java de JMeter et un code script dans un autre langage de programmation.

Plus précisément ces éléments BSF permettent d’avoir accès à un certain nombre d’objets internes de JMeter (comme l’objet SampleResult correspondant au résultat courant : temps de réponses, nom, latence, etc.), tout en pouvant effectuer des opérations (de programmation) dessus avec un langage de programmation qui n’est pas forcément du Java (le langage utilisé pour créer JMeter).

BSF supporte un grand nombre de langage, soit directement c’est-à-dire distribué dans l’archive binaire de BSF, soit directement par les langages eux-mêmes, qui dans ces cas-là proposent leur moteur BSF.

Dans ce billet, nous allons voir comment faire du Groovy (définit comme un langage dynamique et agile pour Java) dans JMeter à travers ces éléments BSF. Continue reading ‘JMeter et Groovy : exemple d’échantillon BSF/Groovy’ »

Pour faire suite à ce billet qui montre un test JMS de type Point-à-Point, voici un autre test JMS mais cette fois avec la notion d’abonnement (subscriber) et de publication (publisher).

Comme pour le premier test, nous continuons avec la messagerie orientée message (MOM) Apache ActiveMQ.

Après avoir téléchargé l’archive binaire d’ActiveMQ, on le décompresse, puis on le démarre avec ces commandes :

cd <Repertoire_ActiveMQ>
./bin/activemq start

Il est possible de vérifier que le serveur ActiveMQ fonctionne bien en se connectant sur http://localhost:8161/admin/ correspondant à l’URL de l’interface d’administration.

Du coté de JMeter voici comment ce présente notre petit test :

Tout d’abord, on notera la présence de 2 Groupes d’unités : un réservé pour l’Abonnement et un autre pour la Publication. Continue reading ‘JMeter : petit test JMS Publication – Abonnement avec ActiveMQ’ »

Depuis la version 2.4 de JMeter, un nouvel sous-élément du récepteur Arbre de résultats est apparu, il s’agit du Testeur de RegExp.

Avant de vous montrer comment le trouver et l’utiliser, parlons-en un peu.

Comme vous le savez peut-être, JMeter dispose d’un élément Extracteur Expression régulière dans la catégorie Post-processeurs. La vocation de cet élément Extracteur Expression régulière est d’extraire à partir d’une expression régulière une ou plusieurs chaînes de caractères depuis la réponse reçue d’un échantillon de test. La puissance en termes d’extraction de données de cet élément est très forte, cependant, il est parfois peu aisée de trouver du premier coup la bonne expression régulière qui fera ce que vous voulez. En effet, vous devez jouer et rejouer le scénario pour tester votre expression régulière tant qu’elle n’est pas au point.

C’est là qu’intervient le Testeur de RegExp. Continue reading ‘JMeter : le testeur d’expression régulière’ »

Imaginez- vous en mission pour effectuer un test de charge avec votre logiciel favori JMeter. Vous allez suivre le processus habituel :

1. Identifier le scénario fonctionnel qui sera rejoué par les utilisateurs virtuels
2. Enregistrer ce scénario dans JMeter au travers d’un session de navigation avec votre navigateur
3. Affiner le scénario (variabiliser ce qui doit l’être, ajouter des assertions réponses, etc.)
4. Lancer votre tir

Le problème, c’est que vous avez accès à l’application cible pendant une période limitée, genre 15 min, ou bien que vous n’avez pas accès directement à l’application, vous devez passer un poste de travail pour accéder à l’application, ce poste étant bien entendu moins bien que votre ordinateur (genre c’est pas Linux )

Que diriez-vous d’enregistrer votre session de navigation complète, c’est-à-dire les requêtes avec leurs paramètres mais surtout les réponses reçues par le navigateur, afin de pouvoir affiner votre scénario « à froid », sans connexion avec l’application cible, ou carrément tranquillement à la maison ?

Voici le mode d’emploi. Continue reading ‘JMeter : Sauvegarder dans un fichier votre session de navigation lors de l’enregistrement de vos scénarios fonctionnels’ »

Vous trouverez à cette adresse les résultats du sondage JMeter. Il y a eu 30 réponses, merci à tout ceux qui ont répondu.

Dans ce sondage, je remarque les points suivants :

• La moitié d’entre-vous utilise JMeter depuis moins de 6 mois (et donc je suppose viennent sur ce blog ou sur le groupe pour avoir de l’assistance )
• On utilise JMeter plutôt en fonction des projets/missions (pas trop de « métrologue » dans l’assemblée ?)
• C’est sur Windows que JMeter est le plus utilisé (normal puisque c’est un logiciel de « poste client ») cependant Linux s’en tire très bien avec pratiquement 1/3 des utilisateurs (ça c’est ma petite sensibilité avec Linux…)
• Malheureusement (mais prévisible), c’est avec un affichage en Anglais que plus de la moitié d’entre-vous utilise JMeter. (là c’est un petit pincement au cœur, mais bon, je comprends car moi aussi j’ai commencé à utiliser JMeter en anglais au début, ensuite je suis passé à la traduction de l’interface, et maintenant j’utilise principalement la version française (sauf pour les développements sur JMeter))

Concernant l’utilisation de JMeter : Continue reading ‘Sondage JMeter en français 2010 : résultats’ »