Nous allons, dans ce petit billet, monter un scénario JMeter pour exécuter un test d’un serveur de Messagerie Orientée Messages (MOM). Pour ce dernier, nous allons prendre Apache ActiveMQ, sachant qu’il existe d’autres MOM comme IBM WebSphere MQ (ex-MQSeries), Tibco, etc.
Ici, nous allons montrer un test JMS en Point-à-Point. L’autre type de test possible en JMS est la Publication-Abonnement (Publisher-Subscriber), celui-ci fera l’objet d’un autre billet.
Un des pré-requis est d’avoir un serveur ActiveMQ démarré. Pour cela (et pour faire simple), il suffit de télécharger les fichiers binaires depuis le site Apache ActiveMQ, de décompresser l’archive, d’aller dans le répertoire de décompression et exécuter la commande suivante :
./bin/activemq start
Ensuite, vous pouvez vérifier que cela fonctionne en visitant l’interface d’administration à l’adresse suivante http://localhost:8161/admin/
On reviens à JMeter maintenant et notre petit tutoriel sur l’utilisation de JMeter pour tester ActiveMQ.
Une étape préalable est de récupérer les fichiers JAR d’ActiveMQ afin de permettre à JMeter de « parler JMS » avec votre serveur ActiveMQ. Le mieux est de prendre l’archive activemq-all-X.X.X.jar (X.X.X en fonction de la version) à partir du répertoire ActiveMQ décompressé, puis de placer le fichier JAR dans le répertoire JMETER_HOME/lib. L’aide officielle pour cette étape est ici.
Voici maintenant notre plan de test tout simple pour illustrer un test JMS sur une file « point à point ».
On aura dans ce plan de test, un groupe d’unités, appelé GU Point-à-Point, avec seulement un utilisateur, qui monte en charge en une seconde et qui fera trois itérations.
Ensuite, on en vient à la Requête JMS Point-à-point qui va faire tout le travail. C’est-à-dire, qu’elle va déposer un message sur une file de requête (Q.REQ) et lire sur une file de réception le message qu’elle a déposé (Q.RPL).
Voici quelques commentaires ou explications sur les champs de cet élément JMS Point-à-point :
| Champs | Valeurs | Commentaires |
| Nom | JMS Point-to-Point ${__time(,TIMESTAMP)} | Afin de faciliter le débogage, j’utilise la date en secondes dans le nom de l’élément (qui s’affichera donc dans les récepteurs de résultats)
Par ailleurs, je dépose dans la variable ${TIMESTAMP} la valeur de la date, pour une utilisation dans le contenu du message (ci-dessous) |
| Fabrique QueueConnection | ConnectionFactory | |
| Nom JNDI de la file d’attente Request | Q.REQ | Le nom JNDI permettant à JMeter de faire la liaison entre la fabrique de connexion et la file |
| Nom JNDI de la file d’attente Receive | Q.RPL | Le nom JNDI permettant à JMeter de faire la liaison entre la fabrique de connexion et la file |
| Type de communication | Requête Réponse (ou Requête seule) | Ici on fait un type de communication Requête (dépôt) puis Réponse (récupération).
L’autre option possible est la requête seule (donc les messages doit être dépilés via soit une autre application, soit une requête JMS Abonnement) |
| Champs alternatifs pour la correspondance de message | ||
| Utiliser l’ID du message Request | non coché | On peut laisser JMeter utiliser l’identifiant du message Request (dépôt) pour faire la corrélation entre le message déposé et récupéré |
| Utiliser l’ID du message Response | non coché | On peut laisser JMeter utiliser l’identifiant du message Responce (récupération) pour faire la corrélation entre le message déposé et récupéré |
| Délai (ms) | 30000 | Ce délai d’attente est utilisé lors de la réception du message (File Receive), si JMeter ne récupère rien dans le délai (ici de 30 sec), alors l’élément sera marqué en erreur |
| Utiliser un mode de livraison non persistant ? | non coché | |
| Contenu | « Message de test ID TEMPS = ${TIMESTAMP} » | Voici le contenu de mon message. |
| Propriétés JMS | ||
| JMSCorrelationId | Milamber-${__time(,)} | Ici, j’ai mis mon propre identifiant de corrélation de message, Milamber accolé de la date (en nombre de secondes depuis le 1er Janvier 1970) |
| Propriétés JNDI | ||
| Fabrique de connexion initiale | org.apache.activemq.jndi.ActiveMQInitialContextFactory | La classe à invoquer pour créer une connexion sur la messagerie orientée message. |
| queue.Q.REQ | example.A | Correspondance entre le nom JNDI de la file (Q.REQ) et le nom réel de la file dans ActiveMQ (example.A) |
| queue.Q.RPL | example.B | Correspondance entre le nom JNDI de la file (Q.RPL) et le nom réel de la file dans ActiveMQ (example.B) |
| URL du fournisseur | tcp://localhost:61616 | L’adresse et le port pour attaquer l’ActiveMQ. |
Il ne reste plus qu’à lancer le micro-test :
L’arbre de résultats nous montre une exécution réussie 😉
Et là, la capture d’écran du contenu de message.
Pour revenir à ActiveMQ et sa console, à partir de celle-ci on peut voir (surveiller) les messages déposés/lues dans les files.
On peut également voir les connexions ouvertes par JMeter pendant le tir. Au total 2 connexions (une pour le dépôt et une pour la lecture).
Quelques commentaires :
- En interne, JMeter démarre le JMS Listener (le processus d’écoute) sur la file de réception avant même le début du test (au moment de la compilation de l’arbre du script JMeter). Ce qui signifie que le nom de la file ne supporte pas les variables JMeter non définies au moment du lancement du test (donc une variable récupérée via un extracteur d’expression régulière ne fonctionne pas, ou bien des noms de files JMS qui sont récupérées via une Source de données CSV).
- L’aide officielle de JMeter sur les tests JMS est ici (JMS Point-to-Point) et là (Building a JMS Point-to-Point Test Plan).
- Un lien vers un tutoriel IBM pour utiliser JMeter avec WebSphere MQ
./