Certification IBM WebSphere Application Server Network Deployement V8.0 réussie

Histoire de faire partager une bonne nouvelle me concernant, je vais viens de réussir la certification IBM WebSphere App Server Network Deployment V8.0, Core Admin (code 000-317)

Et oui, je n’en parle pas souvent sur ce blog, mais depuis un peu plus d’une dizaine d’années, je travaille sur des projets WebSphere (en tant qu’expert et architecte). J’ai déjà deux certifications WebSphere (admin et dev), mais elles commencaient à dater un peu, donc un petit renouvellement s’est imposé pour montrer que le niveau est toujours là.

Quelques mots sur le test de certification : Continuer la lecture de Certification IBM WebSphere Application Server Network Deployement V8.0 réussie

Test de performances et analyses avec WebSphere Application Server (et JMeter)

Un petit billet pour pointer sur cet article Performance testing and analysis with WebSphere Application Server, qui décrit comment faire un test (simple) de charge avec Apache JMeter sur une application J2EE hébergée sur un serveur WebSphere Application Server, puis comment procéder pour recherche le goulot d’étranglement avec les outils internes à WebSphere et d’autres outils IBM.

Ce n’est pas le premier billet qui utilisent JMeter sur le site IBM developerWorks, mais j’aime toujours ce type de billet, car d’une part, moi aussi j’utilise JMeter pour ce genre de test, mais également je travaille régulièrement sur des architectures WebSphere (définition, mise en place, recherche de cause de problème et bien entendu tests de charge :-)).

Noter aussi que dans ce billet, la recherche du point de saturation est faite d’un point de vue « débit » (throughput – cf. Figure 7)) sur une seule requête, et non temps de réponses « trop grand » comme généralement dans les tests de charge de site Web.

SAP Memory Analyzer : voilà un vrai outil pour analyser des Heap Dump 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 !