mercredi 20 janvier 2010

Paris JUG - Soirée performance

Résumé de cette soirée animé par Kirk Pepperdine et Dan Hardiker, tenant le site http://www.kodewerk.com/.

La présentation fut similaire à celle ayant eu lieu au Devoxx 2009 (visible ici http://beta.parleys.com/#sl=1&st=5&id=1594) donc vous pouvez voir les transparents.

Ambiance bien sympathique surtout par la dynamique du duo.

Coté technique, dans l'ensemble, la présentation portait plus sur le coté méthodologie et bonnes pratiques de l'amélioration des performances d'une application. Seuls des outils de base mais indispensable ont été utilisés (suivi des processus système, JMeters tiré du profiling netbeans ou encore Thread Dump Analyzer).

Kirk nous a présenté un ensemble d'anti-patterns liés aussi bien à la technique qu'à la méthodologie.

La panique.
Erreurs : ignorer des éléments clés, pointer du doigt ("Ca vient de la base de données ou du reseau !"); la pression des utilisateurs et des manageurs; beaucoup de stress.

Pas de "stress testing".
Erreur : utiliser le navigateur pour faire des tests (non répétable, difficile à réaliser).
Besoin : avoir une specification claire du besoin du client en terme de performance; Aucune réponse de plus de 3 sec.

"Shot in the dark".
Erreur : ne pas travailler sur des intuitions, par exemple, code propre et non propre ont souvent les memes performances. Faire des optimisations de facon prématuré est inutile.
Besoin : mesurer pour connaitre l'origine du probleme. Identifier les principaux consommateurs. Tester chaque niveau de l'application, dans l'ordre Hardware puis JVM/OS puis application puis le client associé à des patterns d'utilisation.
Par exemple si au niveau de l'OS, si les ressources affectés au processus se partagent également entre l'application et sa gestion par le systeme, il y a surement un probleme de threads.

Dans la scéance des questions / réponses, il est ressorti qu'un des principaux objectifs du consultant sur des questions de performance va etre de faire parler les différents acteurs du projet. Les problemes de performances Java se repartissent à 40% sur des problemes de mémoire et à 40% sur des problemes d'accès base de données (JDBC).

Allez le compte rendu + wave par Olivier Croisier : http://thecodersbreakfast.net/index.php?post/2010/01/23/Paris-JUG-Performance-Kirk-Perpperdine

Aucun commentaire: