Architectures de production informatique

...

bla

Compte rendu du livre de S Natkin "Les protocoles de sécurité sur Internet"

Formation Java performance chez Xebia

En décembre 2011 j'ai assisté à la formation "Java Performance Tuning" chez Xebia à Paris. Le but de cette formation est de pouvoir diagnostiquer rapidement les problèmes de performances des applications Java.On se concentre ici sur les applications web n-tiers. La plupart du temps on considere une architecture 3-tiers classique. Cet article présente quelques éléments de la formation qu'on peut retrouver en partie sur cette page (en Anglais) : http://www.infoq.com/articles/the-box

Lorsqu'on est face à une application qui souffre de problèmes de performances, un des 1ers reflex est de se jeter sur le code. Ce n'est pourtant pas la bonne solution. Certes, à terme nous serons probablement amenés à modifier le code de l'application, mais il faut au préalable cibler précisemment ce qui ne va pas. Kirk Pepperdine a developpé une méthodologie pour analyser et trouver efficacement les goulots d'étranglement.

On représente une application comme un ensemble de couches qui constituent la "boite". 
Quand on souhaite analyser un problème de performance, il faut considérer ces 4 éléments.

Hardware et Système d'exploitation (OS).
Les ressources du serveur qui heberge l'application impactent les performances. Parmi les éléments à considérer, on peut citer la CPU, la RAM, les disques...

La JVM.
Il existe une centaine d'options paramètrables sur la JVM. La plupart du temps, les valeurs fixées par défaut suffisent. Cependant, certains paramètres (mémoire allouée, stratégie du Garbage Collector, threads...) peuvent influencer fondamentalement le comportement global de la JVM.

Application.
Le code Java. En particulier la gestion des sessions, les threads, les accès aux données, boucles infinies...

Les acteurs.
Par "acteurs" on entend les utilisateurs qui agissent sur le système via une interface mais cela peut être aussi un batch. En particulier, pour les utilisateurs humains, il faut identifier leurs actions et leur nombre. Certains problèmes ne surviennent que lorsque l'application est chargée au dela d'un certain seuil par exemple.

Rien de révolutionnaire la dedans. Mais ce qui est intéressant c'est la démarche associée. Un problème de performance est perçu au niveau de l'utilisateur comme une action qui prend un temps excessif par rapport à ce qui est attendu. Il faut donc identifier le goulot d'étranglement et la couche associée. En d'autres termes quel est le consommateur principal des ressources d'une couche ? On se sert de l'arbre de décision suivant.

Au début, on va regarder quelle est la consommation CPU du "noyau". Si plus de 10% du CPU est consacré au noyau, cela indique que les ressources systèmes sont trop sollicitées. Cela peut être le signe que l'application swap sur le disque, ou qu'il n'y a pas assez de threads systèmes libres, ou beaucoup d'I/O sur disque. Bref, une baisse de performance dûe à une sur-utilisation des ressources hardware/OS.

Si ce n'est pas le cas, le diagramme indique de regarder la CPU dédiée à l'application. Si la CPU n'est pas à 100% alors il n'y a pas de consommateur principal et l'arbre n'est plus utile. En revanche, si la CPU dédiée à l'application est presque constamment à 100%, alors on va regarder les paramètres de la JVM. En particulier la mémoire allouée et les paramètres du Garbage Collector (Le paramètrage du Garbage Collector fera l'objet d'un article futur).

Si le Garbage Collector est optimisé alors il faut chercher du coté du code de l'application.

Regardons l'image suivante.

Elle a été prise sur un serveur Windows 2003 (quad core avec 2 Go de RAM) faisant tourner un serveur Weblogic. Une webapp qui sert 20 utilisateurs est installée sur le serveur Weblogic. Cette application effectue des requêtes vers une base Oracle installée sur un autre serveur via un connecteur réseau de 1 Gbit

Les utilisateurs qui accèdent à l'application via un navigateur disent que les temps de réponse sont extrêmement longs. Le DBA et les gens du reseaux rapportent que les requêtes s'exécutent bien et que le lien réseau n'est pas surchargé.

Le graphique montre clairement que la CPU dédiée au système est très importante. Ceci indique que quelquechose dans le code de l'application entraine une consommation CPU exagérée.

Les taches dédiées au noyau incluent : la gestion de la mémoire, le changement de contexte, l'ordonnancement des threads, les interruptions, les entrées sorties...Sur la figure on peut voir qu'il y a beaucoup de mémoire disponible et donc éliminer cette piste comme source du problème.

Sur un ordinateur, les threads sont traités à tour de rôle par le CPU. C'est cette alternance qui permet de traiter plusieurs process en même temps. Le temps consacré à chaque thread est fixe. Quand un thread a consommé son temps imparti, il est remplacé par un autre (changement de contexte). C'est l'ordonnanceur des threads qui s'occupe de cette tâche et cela consomme de la CPU.

En temps normal, cette consommation CPU est négligeable.Cependant, il arrive qu'un thread soit retiré de la CPU avant d'avoir utilisé sont temps de travail imparti. C'est le cas notamment, lorsqu'un thread est bloqué sur une entrée/sortie ou en attente car il existe un verrou (lock). Si cela arrive fréquemment, la consommation du CPU va monter significativement et impacter les performances globales. Dans notre cas, c'est le changement de contexte qui est la cause la plus probable de l'utilisation intensive du CPU. A ce point là, nous avons une idée plus précise de ce qu'il faut regarder dans le code, même s'il existe de nombreuses causes qui peuvent induire un changement de contexte exagéré. Nous pouvons également utiliser un outil (process explorer, CodeAnalyst...) pour superviser l'activité du reseau, des disques ou voir s'il n'existe pas des threads lockés.

Dans le cas étudié, c'est le code d'accès à la base qui était mal conçu et provoquait de nombreux locks.

A titre de comparaison voici une image d'un serveur "sain".C'est un serveur Windows 2003 (dual core, 3.5 Go de RAM) qui héberge 4 Tomcats Sur chacun des Tomcats plusieurs applications sont installées.Le serveur est sollicité mais on voit que la ligne rouge qui témoigne de l'activité système reste à un niveau assez bas.

Conclusion

Lorsqu'on regarde le code d'une application, on peut toujours trouver quelquechose à optimiser. Il est donc difficile d'identifier rapidement les cause du goulot d'étranglement si on se plonge dans le code directement. Nous avons là une démarche rationnelle et méthodique qui permet de faire un tri efficace dans la recherche des causes de problèmes de performances.

La formation "Java performance tuning" est très intéréssante. Cet article correspond au 1er "chapitre" de la formation. Mais on y aborde beaucoup de points (la JVM, le Garbage Collector...) et de nombreux outils sont utilisés (profilers...). De plus Kirk Pepperdine est très sympathique et pédagogue. Il faut s'accrocher car c'est en Anglais et le rythme est assez élevé mais ça en vaut la peine. Clairement une formation à recommander à tout administrateur de serveur J2EE.

En 2006, j'étais inscrit au CNAM de Paris où je préparais un diplôme d'ingénieur en informatique. Une des épreuves était l'examen probatoire. Le sujet de cet examen est : "Les dispositifs à tolérance de panne".

Ca correspond tout à fait aux problèmatiques de production informatique. Quels sont les moyens à mettre en oeuvre pour assurer que les applications fonctionnent même lorsqu'un des éléments est défaillant ?

Ce document passionnant ;-) présente les dispositifs tels que les cluster, les systèmes RAID...enjoy !!

Vous pouvez utiliser librement ce document si vous le souhaitez mais merci de mentionner l'auteur et d'où il vient.

 Dispositifs_a_tolerance_de_panne

Wizinfo,

Création du blog. Je compte publier ici des articles, reflexions, avis, réactions... sur l'informatique.

En particulier sur les architectures de production, Java coté serveur, la sécurité, les performances, les méthodes utilisées sur les environnements de production.