Le profiling Java

Lorsqu’un développeur produit du code source, il doit s’assurer que plusieurs critères essentiels soient satisfaits. Ceux-ci sont nombreux (la maintenabilité, la modularité, …) mais aujourd’hui nous ne nous intéresserons qu’à l’un d’entre eux : la rapidité d’exécution.

Si la rapidité d’exécution d’une application n’est pas satisfaisante, il est possible d’instrumenter cette dernière afin d’identifier les causes du ralentissement. L’exécution produira alors une série d’indicateurs permettant d’isoler les portions de codes non optimales.

Vient alors le moment où le développeur Java doit s’outiller pour améliorer son code. Plusieurs choix s’offrent à lui :
– Utiliser le profiler intégré à son IDE si celui-ci en propose un
– Ajouter un plugin à son IDE
– Utiliser une application tierce

Cet article ne se veut pas exhaustif au niveau des profilers disponibles. Il est plutôt là pour présenter deux alternatives très différentes dans le domaine du profiling d’applications Java.

JRat

Java Runtime Analysis Toolkit rentre dans la catégorie des applications tierces qui instrumentent le bytecode Java. Ce profiler, développé depuis 2001, a connu plusieurs évolutions majeures au sein de la version 1-alpha2 dont le passage de BCEL à ASM pour ce qui est de la technologie de manipulation/instrumentation du bytecode. Le temps d’injection s’en est trouvé sensiblement amélioré.

Il existe deux méthodes pour utiliser JRat :
– L’ancienne : depuis le JRat Desktop, choisir le .class, le package ou bien le JAR, WAR ou EAR à instrumenter (ce qui permet de gérer la portée du profiling) puis lancer l’application sans oublier de placer le JAR de JRat dans le classpath.
– La nouvelle apparue depuis la version 1-alpha2 : instrumenter le code à la volée grâce à [l’option -javaagent->http://javahowto.blogspot.com/2006/07/javaagent-option.html] apparue dans le JDK 1.5.

Ainsi instrumentée, chaque méthode consigne dans un fichier le delta de temps entre l’entrée et la sortie.
A l’issue de l’exécution, le fichier peut être ouvert dans le JRat Desktop, il présente les informations suivantes :

Les points forts de JRat sont clairement :
– Sa facilité de mise en œuvre qui le rend parfait pour les utilisations ponctuelles
– Sa gratuité
– Une journalisation des performances si le code reste instrumenté

Quelques reproches peuvent être formulés :
– Le profiling de la mémoire est quasi inexistant. C’est pourtant une fonctionnalité intéressante pour optimiser les applications avides de mémoires
– Résultats à postériori
– Les limites de commodités et en terme de fonctionnalités seront vite atteinte sur un projet conséquent
– Le code instrumenté depuis le JRat Desktop aura une dépendance avec le JAR de JRat jusqu’à la prochaine recompilation. Il est donc crucial de dupliquer le bytecode avant injection si vous ne disposez pas des sources.

VisualVM

Face à JRat, nous pouvons trouver VisualVM qui est basé sur JFluid (à la base aussi du profiler de NetBeans), un projet interne aux laboratoires de Sun.

Le fonctionnement est assez simple : un exécutable permet de lancer VisualVM qui présente dans une liste tous les processus Java lancés sur la machine. Il est aussi possible de se connecter à une JVM distante grâce à JMX.

A noter qu’il existe un plugin Eclipse permettant de lancer le profiler en parallèle de l’application instrumentée.

Au cours de l’exécution, voici quelques uns des indicateurs que présente VisualVM :

Ce graphique présente aussi l’activité du garbage collector.

Cet indicateur permet de nous rappeler quels sont les objets dont il faut limiter l’instanciation.

De la même manière que le graphique CPU, ce suivi temps réel de la mémoire nous permet de comprendre l’impact de nos actions applicatives sur les ressources systèmes.

Graphique très pratique pour comprendre et débugger les applications utilisant abondamment les threads.

Cet arbre d’appel présente le même niveau d’information que JRat.

Les avantages de ce profiler sont nombreux :
– Profiling d’une JVM distante
– Richesse des informations présentées à l’utilisateur
– Extensibilité par plugins (par exemple un plugin GlassFish qui est en cours de développement permettra entre autre de suivre le nombre de sessions actives, de transactions effectuées et d’instrumenter les webapps déployées)
– Présentation en direct des résultats (et non à posteriori comme le propose JRat)
– La richesse fonctionnelle ne pénalise pas la mise en œuvre qui reste très simple

VisualVM comporte quand même quelques défauts :
– Le profiling CPU ne peut se faire que sur une application tournant sur une JVM 1.6 ou supérieure
– Le démarrage du profiling n’est pas synchronisé avec le démarrage d’une application

Conclusion

Comme nous avons pu le voir ces deux outils présentent chacun des défauts et des qualités indéniables.

Ils n’ont en revanche pas le même domaine d’utilisation : JRat est plutôt destiné à du profiling occasionnel contrairement à VisualVM qui excellera là où les faiblesses de JRat se font sentir : le suivi de la mémoire.

Globalement VisualVM pourra satisfaire tous les besoins tout en restant simple d’accès. L’inverse n’est pas forcément vrai, JRat ne sera pas suffisant pour les besoins d’un projet conséquent.