Ce billet est une suite ou mise à jour de ce premier billet parlant d’un script BeanShell pour enregistrer des données dans un fichier texte.
Cette fois-ci, ce sera en utilisant un élément Post-Processeur JSR223, et surtout la dernière version de JMeter 3.0 avec ses nouvelles icônes et autres améliorations depuis l’époque du premier billet (2009!)
Soit le plan de test suivant :
Si vous souhaitez vous lancer dans le développement de nouvelles fonctionnalités ou tout simplement corriger une anomalie sur JMeter, voici une petite procédure pour l’installation du référentiel SVN publique du projet dans votre Eclipse, puis les premières étapes indispensables pour son lancement depuis Eclipse.
Pré-requis :
Eclipse Indigo (mais les versions suivantes doivent fonctionner aussi bien sur) Continuer la lecture de Installation du référentiel SVN du projet JMeter dans Eclipse et configuration pour le lancement de JMeter
Un petit billet pour pointer cet article de blog : Générer des tests JMeter à partir de Selenium, publié hier.
Il est intéressant car il montre l’utilisation intelligente de JMeter et Selenium, mais également comment modifier/compléter de manière programmatique son script JMX.
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. Continuer la lecture de JMeter et Groovy : avoir des requêtes HTTP concurrentes
JMeter dispose de deux modes de fonctionnement, un mode GUI et un non-GUI, « GUI » signifiant Graphical User Interface, c’est-à-dire un mode de fonctionnement avec une interface graphique utilisateur qui permet de créer, éditer un script et lancer un test de charges et autres choses. Le mode non-GUI ne permet pas de manipuler un script, mais simplement de lancer le script de test de charges.
Pourquoi ce mode non-GUI ? Parce qu’en mode GUI, JMeter peut être gêné par la gestion du ‘graphisme‘ pendant qu’il est en train d’exécuter un test de charges. Et cela peut avoir un impact sur la qualité des résultats du tir.
En effet, sur le poste JMeter, la gestion du mode graphique impacte : Continuer la lecture de JMeter : Pourquoi exécuter son test de charges en mode non-gui (sans interface graphique) ?
Un fonctionnalité pratique du framework de logging Apache Log4J est le NDC (pour Nested Diagnostic Contexts). Ce dernier permet de tracer et suivre plusieurs instances d’un même traitement dans un seul fichier de log. Une utilisation typique est le fichier de log d’une application web s’exécutant sur un serveur d’applications, car plusieurs instances d’une même servlet (et de plusieurs servlets) s’exécutent en même temps pour servir les utilisateurs.
La fonctionnalité permet donc de mieux comprendre le déroulement d’un traitement, en particulier lors qu’un problème survient lors d’un tir de charges ou sur un environnement en production. Et imaginons que ce problème ‘ne se reproduit pas’ en environnement de recette / développement, et donc l’origine pourrait être ces accès multiples en même temps… Continuer la lecture de Utilisation de NDC de Apache Log4J pour tracer et suivre l’exécution d’une application Java
Vous avez développé une application JEE, et depuis son passage en production au moins une fois par jour il y a une erreur Java « OutOfMemoryError ». La première réaction a été de dire : mauvaise configuration de la taille maximale de la JVM… vous avez préconisé 1Go de Max Heap Size, cela n’a pas fonctionné, l’erreur OOME arrive encore… Alors on est passé à 2Go… Toujours l’erreur d’OOME… Aie, et que faire…
Quand vous êtes à ce point, vous pouvez être certain que vous avez une fuite de mémoire (memory leaks) quelque part. Oh, ce n’est pas que vous êtes un mauvais développeur 😉 et que vous ne savez pas bien gerer la mémoire, en effet, parfois un problème de fuite de mémoire peut survenir à cause d’une fonctionnalité activée du serveur d’applications de production et qui rentre en « conflit » avec une brique de l’application. (Je citerai un exemple vécu : le cache (activé) JDBC de la source de données WebSphere 5.1 et un framework maison de mapping O/R)
Quand on a un problème d’OutOfMemory, on commence souvent par activer le mode verbeux du Garbage Collector (GC), c’est une très bonne idée, cela permet d’avoir une petite idée sur le déroulement du problème de mémoire (on peut utiliser l’outil Extensible Verbose Toolkit d’IBM pour ce travail, cf références). Cependant c’est insuffisant pour trouver la cause du problème. Quelques recherches sur Internet vous apprennent qu’il est possible d’avoir une image de la mémoire Java avec la génération d’un « heap dump », ensuite il suffit de l’analyser pour trouver la cause de la fuite de mémoire. Facile à écrire, mais dur à faire…
Continuer la lecture de SAP Memory Analyzer : voilà un vrai outil pour analyser des Heap Dump Java !
On le sait, Google et son moteur de recherche Web est un outil devenu indispensable à tout informaticien qui se respecte. Pour résoudre des problèmes, rien de tel qu’une bonne recherche sur Google pour trouver la cause du problème et sa solution.
Un nouveau type de moteur de recherche est en train de prendre de l’importance dans la vie des informaticiens orientés développement. Ce sont les moteurs de recherche de code. Google dispose du sien, mais c’est Krugle qui semble faire figure de proue aujourd’hui.
A quoi sert un moteur de recherche de code ? Continuer la lecture de Les moteurs de recherche de code
La Fondation Eclipse vient de sortir Eclipse Europa. Il s’agit de la mise à jour synchronisée de 21 projets permettant ainsi d’assurer une compatibilité entre les sous-projets d’Eclipse et le socle. Europa désigne donc plus qu’Eclipse et plusieurs déclinaisons d’Europa sont proposées :
Chaque déclinaison est composée d’outils adaptés à l’environnement ciblé. Il reste bien sûr possible de faire sa propre déclinaison en téléchargeant individuellement les modules via le mécanisme de mise à jour livré dans Eclipse (socle). Continuer la lecture de Sortie de Eclipse Europa
Eclipse devient incontournable, personne ne dira le contraire. Même Microsoft ! en effet, la revue ‘Redmond Developer news’, destinée aux utilisateurs des produits Microsoft, a publié cet éditorial qui met en avant le fait que l’utilisation d’Eclipse dépasse largement le monde Java et donc que des outils basés sur Eclipse pourraient être de plus en plus utilisés dans le cadre de développements en technologies Microsoft. Continuer la lecture de Dossier Eclipse
