A Devoxx, deux sessions étaient dédiées au thème du tuning de performance en Java : Performance for the performance-shy par Holly Cummins et The not so dark art of performance tunning par Kirk Pepperdine et Dan Hardiker. Nous nous attardons ici sur cette dernière.
Kirk Pepperdine (photo ci-contre) est Java Champion et possède une expertise reconnue dans le domaine des performances des applications Java. On se souvient également de sa présentation en avril 2008 au ParisJUG où il avait fournit un aperçu des problématiques liées à ce sujet.
Dan Hardiker est pour sa part le fondateur d’une entreprise spécialisée dans l’hosting de solutions basées sur Confluence.
La session qu’ils ont tous deux présentée à Devoxx ne se voulait pas exhaustive sur le sujet de la performance, bien trop vaste et complexe pour être traité en une heure, mais cherchait surtout à mettre en avant des principes et des attitudes à adopter.
Les anti-patterns de tuning de performance
La session commence avec la présentation de deux anti-patterns couramment rencontrés lors des procédures d’amélioration de performance. Ces anti-patterns avaient été formalisés il y a trois ans par Kirk Pepperdine : l’absence de test de montée en charge (No stress testing) et le tir à l’aveugle (Shot in the dark).
Aucun test de montée en charge
Il s’agit là d’un cas courant : une application, un nouveau système ou simplement une mise à jour majeure est mise en production sans avoir effectué le moindre test de montée en charge. L’estimation de la viabilité de l’installation se faisant alors sur l’expérience passée et la réactivité de l’application lors des phases de recette.
Bien sûr cela peut très bien se passer. Mais dans certain cas, il en résulte une pure et simple indisponibilité de service due à un écroulement des performances ayant entraîné une saturation des serveurs.
Les tests de montée en charge sont indispensables pour connaître et éventuellement corriger par avance les limitations des applicatifs que l’on va mettre en production.
Tir à l’aveugle
Il s’agit là également d’un comportement courant, mais conduisant à des actions inefficaces voir erronées. Lorsqu’un problème de performance est constaté, l’équipe en charge de l’application fait quelques suppositions et procède immédiatement à des ajustements en conséquence.
Là encore, ce type de comportement peut conduire à une résolution du problème, mais la procédure manque de précision et peut mener à une aggravation de la situation ou à des solutions mal maitrisées et difficilement explicables.
Lorsqu’un problème de performance est constaté, seule la prise de mesure permet de mettre en œuvre des corrections sérieuses car décidées en toute connaissance de cause.
Les causes d’augmentation du temps de réponse
Il est important de connaître les points pouvant être responsables de l’augmentation du temps de réponse au sein d’un système. Si l’on considère un système 3 tiers classique, les localisations de ces points sont nombreuses :
De part la nature distribuée de l’architecture 3 tiers, le temps de réponse est en général consommé autour de l’envoi des requêtes et de la réception des réponses. Cette latence peut alors être causée par l’OS, la JVM, le middleware ou par l’application. Il est important de considérer l’ensemble de ces acteurs.
Les outils de diagnostic
Kirk Pepperdine et Dan Hardiker ont également présenté deux outils très courants et simples d’utilisation pour faciliter le diagnostic des applications présentant des problèmes de performances :
- VisualVM : cet outil très populaire est disponible en standard dans le JDK depuis sa version 6.0. Il permet d’analyser le comportement du garbage collector et d’observer les métriques JMX d’un serveur d’application.
- TDA (Thread Dump Analyser) : ce plugin pour VisualVM permet d’effectuer des analyses de thread dumps. Cette analyse permet d’aider à localiser les locks ou les parties de code consommant la majorité du CPU en montrant l’activité de chaque thread d’une JVM à un instant donné.
Conclusion
A Devoxx, il est toujours intéressant d’observer la fréquentation des différentes sessions. Si le succès de certains sujets tels que JEE 6, Spring 3.0, Maven 3.0 ou encore JDK7 est très facilement prévisible, celui du tuning de performance en Java est moins évident à priori. Pourtant les deux sessions dédiées à ce sujet ont fait salle comble. Cette tendance montre que ce sujet concerne beaucoup de monde mais reste peu maitrisé…
L’approche de Kirk Pepperdine et Dan Hardiker présentée ici est intéressante car ils s’efforcent de considérer la problématique des performances d’un point de vue global : alors que le développeur se focalise principalement sur son code pour améliorer les performances d’une application, il est nécessaire de considérer la question de la performance à tous les niveaux – l’application, le middleware, la JVM, la base de données, le matériel, le réseau – pour être efficace. En ce sens, la performance est une problématique globale et non locale.
Les lecteurs intéressés par ce sujet noteront que Kirk Pepperdine proposera pour la première fois en France, une formation en Janvier à Paris où il aura l’occasion de développer en détail les connaissances théoriques et pratiques liées au tuning de performance en Java.