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. En effet, avec ces deux Groupes d’unités on va demander à JMeter de gérer « deux utilisateurs virtuels » indépendamment, l’un chargé de publier des messages, l’autre chargé de profiter de son abonnement à la file de messages c’est-à-dire la réception des messages publiés par l’autre utilisateur.
Regardons en détail :
Tout d’abord, on a le Groupe d’unités réservé à l’Abonnement, c’est-à-dire la récupération des messages publiés par le publieur. Ici on fait simple : 1 utilisateur virtuel qui fait 4 itérations.
Ensuite vient la requête JMS Abonnement avec les paramètres suivants :
- Fabrique de connexion initiale : org.apache.activemq.jndi.ActiveMQInitialContextFactory
- URL du fournisseur : tcp://localhost:61616 (les valeurs par défaut de ActiveMQ)
- Fabrique de connexion : ConnectionFactory
- Destination : dynamicTopics/MyStaticTopic1 (ici on utilise une fonctionnalité d’ActiveMQ avoir des Topics (sujets) qui sont créés dynamiquement dès qu’il est sollicité) (sinon il faut créer le topic via l’interface d’administration d’ActiveMQ)
- Evaluer : Au démarrage. Ici c’est une nouvelle fonctionnalité ajoutée après la version 2.4. C’est en effet une version de développement que j’utilise ici. Par défaut dans les versions < 2.4 le nom de la Destination est « static », il est lu au démarrage du test (avant même le lancement des unités d’exécution) et reste figé durant tout le tir, ce qui a pour conséquence d’interdire une valeur contenant une variable JMeter). L’option « Au démarrage » correspond à cette fonctionnalité. L’option « A chaque échantillon » demande à JMeter de procéder à l’évaluation de la valeur de la Destination juste avant l’exécution de la requête. Cette option permet d’avoir des variables JMeter dans le champ Destination.
- Nombre d’échantillons à agréger : 1 (on récupère 1 seul message par exécution)
- Délai : 10000 ms correspondant au temps d’attente maximum que la requête JMS Abonnement va patienter pour recevoir un message avant de se mettre en échec de récupération.
Maintenant on passe au Groupe d’unités réservé à la Publication.
Même traitement : 1 utilisateur virtuel qui fait 4 itérations. (On garde ainsi une cohérence avec le groupe d’unités Abonnement.)
Ici on a l’élément Action test qui va faire faire une pause de 2 secondes à l’unité. Pourquoi ? Parce qu’il faut (pour ce scénario) être certain que le topic (sujet) possède bien des requêtes d’Abonnement en écoute avant la publication d’un message. On laisse ainsi le temps au Groupe d’unités Abonnement d’avoir sa requête en écoute de la file.
On regarde maintenant les paramètres de la requête de Publication JMS :
- Fabrique de connexion initiale : org.apache.activemq.jndi.ActiveMQInitialContextFactory
- URL du fournisseur : tcp://localhost:61616 (les valeurs par défaut de ActiveMQ)
- Fabrique de connexion : ConnectionFactory
- Destination : dynamicTopics/MyStaticTopic1 (ici on utilise un fonctionnalité d’ActiveMQ avoir des Topics (sujets) qui sont créés dynamiquement dès qu’il est sollicité) (sinon il faut créer le topic via l’interface d’administration d’ActiveMQ)
- Evaluer : Au démarrage. (voir l’explication ci-dessus dans les paramètres de la requête JMS d’Abonnement)
- Nombre d’échantillons à agréger : 1 (on envoi 1 seul message par exécution)
- Message texte: un simple message avec une fonction JMeter (time) pour avoir un timestamp.
Voilà, il reste maintenant à tester l’exécution du scénario. Le serveur ActiveMQ est bien démarré, on lance le script (un petit CTRL-R).
Dans le récepteur Arbre de résultats, on peut observer les résultats. On peut y voir une alternance entre la Publication et l’Abonnement. (après chaque publication, le message publié est reçu par l’échantillon Abonnement).
Avec l’onglet Requête du récepteur Arbre de résultats, on peut avoir les détails de la requête JMS, en particulier le JMSMessageId qui permet de faire (si besoin) un rapprochement entre l’émission et la réception des messages JMS.
Pour finir, on regarde un élément JMS Abonnement, qui lui, indique qu’un message a été correctement reçu et affiche les détails de la requête JMS, avec son JMSMessageId.
On notera que : la requête JMS Abonnement arrive après la publication (ce qui est normal) dans l’arbre de résultats, bien que la date de début d’échantillon (onglet Résultat de l’échantillon) est 2 secondes plus tôt que la requête JMS Publication précédente. Du coup le temps de réponse est de 2022 ms, car 1/ les deux Groupes d’unités démarrent en même temps, 2/ mais celui de la Publication a un élément Action test effectuant une pause de 2 secondes, 3/ donc l’élément JMS Abonnement attends 2 secondes que l’élément Publication envoi son message, 4/ et ainsi, on peut calculer (grossièrement) un temps de réponse (récupération du message) réel ici de 22 milli-secondes (2022 – 2000 = 22).
Voilà pour cette très petite introduction aux tests JMS Pub/Sub.
./