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 :
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.
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 !
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
Et hop, quelques jours après l’annonce du passage en licence open source de Java, une nouvelle version voit le jour. Contrairement à ce l’on pourrait penser, il ne s’agit de la version 5 de Java + la licence open source = version 6. Cette dernière est le fruit de deux années de travail des membres du JCP.
Pour un petit rappel historique : la version 1.0 est sortie en 1996, la 1.1 en 1997, la 1.2 en 1998, la 1.3 en 2000, la 1.4 en 2002 et la version 1.5 (renommé 5.0) en 2004. Donc deux ans après on trouve la version 1.6 (6.0). Continuer la lecture de Sortie de Java 6
