19 mars 2011, 10:07
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’ »
14 mars 2011, 1:13
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’ »
11 mars 2011, 8:13
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’ »