Actualité éditeurs / SSII

• Apache Harmony: l’accord final
• Eclipse souffle ses 10 bougies!
• Et un nouveau langage, un!

Agilité

• Jeux agiles, c’est sérieux

Le coin de la technique

• Benchmarking de Cassandra avec Amazon EC2

Evénements de notre communauté en France et à l’étranger

• Velocity Europe à Berlin le 8 et 9 novembre

Actualité éditeurs / SSII

Apache Harmony: l’accord final

Lancé en 2005, le projet Harmony avait pour finalité de créer un JDK distribué sous licence Apache.

Le but était noble, mais le chemin, semé d’embûches: craignant sans doute que la concurrence d’une implémentation open-source et non-virale du JDK ne lui fasse de l’ombre, Sun a toujours opposé une fin de non-recevoir aux demandes adressées depuis 2006 par la Fondation Apache afin d’obtenir un accès au TCK (Technology Compatibility Kit), le précieux sésame indispensable pour qu’Harmony puisse bénéficier du label Java.

L’acquisition de Sun par Oracle en 2009 marqua un tournant dans le monde Java, mais n’a pas vraiment changé l’ostracisme dont souffrait Harmony.

2010 fut l’année des défections: IBM d’abord, son sponsor principal, puis Apple, ont tous deux décidé d’orienter leurs développements vers le projet OpenJDK, l’implémentation open-source mise en avant par Oracle – mais cette fois-ci, il s’agit d’une licence GPL, licence bel et bien virale bien qu’adoucie par l’exception de classpath. C’en fut trop pour la Fondation Apache, qui menaça d’abord de claquer la porte du JCP (Java Community Process) – puis, un mois plus tard, mit ses menaces à exécution.

L’année 2011 démarre sous de meilleurs auspices: c’est la réconciliation, entre Oracle et la communauté Java d’une part; entre Oracle et ses partenaires d’autre part. Mais voilà que cette réconciliation se fit autour du projet OpenJDK, paré désormais de nouveaux statuts fédérateurs et du titre d’implémentation de référence de Java 7. Le projet Harmony se trouva alors définitivement hors-jeu. Google, le seul à avoir misé sur Harmony dont il équipa son système d’exploitation Android, en fait encore les frais: le procès-fleuve qui l’oppose à Oracle est en effet loin de se terminer.

En présentant sa démission en mars dernier, Tim Ellison, alors président du PMC (Project Management Committee) du projet Apache Harmony, avait déjà évoqué l’hypothèse funeste d’un déplacement du projet déjà moribond vers le mouroir des projets Apache. Voilà qui est malheureusement chose faite aujourd’hui: le 29 octobre dernier un vote fut lancé, et le 3 novembre, la décision fut validée à 20 voix contre 2 : c’est donc officiellement la fin du projet Harmony.

Eclipse souffle ses 10 bougies!

Nos confrères d’InfoQ n’ont pas manqué de célébrer cette première décennie du célèbre IDE et retracent sa passionnante histoire, des débuts dans le giron d’IBM, en passant par la création de la Fondation Eclipse en 2004 puis par la « révolution » OSGi, et jusqu’au succès grandissant des rassemblements annuels EclipseCon en Amérique et en Europe. Il en ressort un constat admiratif: que l’on en soit adepte ou bien détracteur, Eclipse a bel et bien marqué de son empreinte le développement logiciel de ces dernières années.

Et un nouveau langage, un!

Et justement, parlons-en d’Eclipse! Edité par la Fondation Eclipse, Xtend est un langage de programmation à typage statique basé sur Java (même système de typage, support complet des generics) mais qui améliore certains de ses concepts. Ce dernier n’a pas pour ambition de détrôner Java, mais d’en étendre les capacités là où il pèche. En effet, il diminue notamment les éléments de syntaxe inutiles et rend le code plus lisible et maintenable grâce à:

• L’inférence de types sur les déclarations de variables, les types de retour, les boucles for et les closures;
• L’invocation des getters et setters en accédant directement à la propriété de l’objet;
• Les point-virgules deviennent optionnels mais aussi les parenthèses pour les méthodes sans arguments. Le mot clé return devient lui aussi optionnel, la dernière expression de la méthode est implicitement considérée comme une valeur de retour.

Techniquement, le code Xtend est compilé en Java et non en bytecode via une compilation incrémentale. De ce fait, le code compilé peut être aisément lu et compris par un développeur Java et être utilisé pour développer sous Android ou GWT par exemple.

Aussi, Xtend vient directement avec un support IDE poussé (Eclipse naturellement), qui offre une expérience de développement quasi similaire au développement en Java standard avec les IDE modernes (coloration syntaxique, navigation, compilation incrémentale, refactoring, etc.). Il est aussi possible de naviguer depuis du code Xtend vers du Java et vice et versa.

Enfin, preuve que Xtend n’a pas pour vocation de remplacer Java mais de le moderniser, le langage est capable de produire uniquement des classes. Pour le reste (interfaces, enums et annotations), il s’appuie sur sur le modèle éprouvé de Java.

Côté « sucres syntaxiques », voici ceux proposé par le langage:

• Les closures, qui restent à ce jour l’une des fonctionnalités les plus attendues pour le langage Java. La documentation montre plusieurs manières de les mettre en oeuvre.
• Un bloc switch amélioré: plus aucun risque d’enchaîner les case par oubli du mot-clé break, le switch à la mode Xtend n’évalue qu’un seul bloc case tout au plus. Il offre aussi la possibilité de lui passer presque n’importe quel type d’objet (exceptés le type primitif boolean et son wrapper). De plus, l’instruction case a été améliorée et peut désormais effectuer toute sorte de tests sur l’objet évalué, et non plus un simple test d’égalité :

switch myString {
 case myString.length > 5 : 'a long string.'
 case 'foo' : 'It's a foo.'
 default : 'It's a short nonfoo string.'
}

Le langage offre aussi la possibilité de typer les instructions case en les préfixant par un type, dans le cas où l’objet passé en paramètre du switch serait étendu par d’autres classes. Dès lors, un opérateur instanceof est évalué et un cast implicite est effecuté pour accéder aux propriétés et méthodes de l’objet:

var Object x = ...;
switch x {
 String case x.length() > 0 : x.length()
 List<?> : x.size()
 default : 1
}

• Les Template expressions qui permettent entre autres de déclarer une chaîne de caractères sur plusieurs lignes sans utiliser l’opérateur de concaténation, mais aussi de déclarer la chaîne avec des guillemets simples (single quotes) pour éviter de multiplier les caractères d’échappement. Cette fonctionnalité permet aussi de formater/indenter et de gérer les whitespaces des outputs aisément.
• Les Méthodes d’extension : Xtend tient son nom de sa capacité à étendre les types via des méthodes d’extensions. Ces méthodes d’extension permettent d’ajouter des méthodes à des types existants sans les modifier.
• Le Multiple dispatch: plus connu sous le nom de surcharge de méthode. Par défaut, Java ou même Xtend lient les méthodes surchargées à la compilation en se basant sur les types statiques des arguments. En déclarant le mot clé dispatch dans la signature de la méthode, le langage permet de définir un ensemble de méthodes surchargées basé sur les types des arguments au runtime.

A noter que Xtend a été développé avec Xtext, un framework pour le développement de Domain Specific Langages, et est basé sur Xbase, un ensemble prédéfini d’expressions qui peuvent être utilisées simplement pour développer n’importe quel langage avec Xtext.

Agilité

Jeux agiles, c’est sérieux

Le buzz de cet automne ce sont les jeux agiles. Le mouvement prend de l’ampleur et de plus en plus d’agilistes en France se tournent vers ce type d’ateliers ludiques mais véritablement efficaces pour leur travail au quotidien, des exemples récents ici, ou encore là le démontrent. Chez Xebia nous utilisons aussi des Innovation Games(R) pour cadrer un projet, résoudre des situations de blocage chez nos clients, ou simplement animer une rétrospective de sprint. Mais les jeux sont aussi un moyen d’apprentissage puissant. Lors de son passage il y a 2 semaines pour une formation Kanban chez Xebia, David Anderson nous a fait jouer à getKanban, un jeu qui permet de simuler la mise en oeuvre d’une gestion de projet façon Kanban. Pendant le jeu, le formateur est là pour nous éclairer sur nos prises de décisions et répondre à nos interrogations, les stagiaires sont acteurs de leur acquisition de connaissance et l’erreur est possible, voire encouragée. Si vous êtes curieux de ces techniques et souhaitez participer à une mise en oeuvre, notez dans vos agendas la SCRUM Night organisée par le French SUG le 7 Décembre et dont le programme sera composé uniquement d’ateliers ludiques et de jeux sérieux (l’agenda est en cours de construction). De son côté, Xebia présentera un sujet intitulé « Ludification du travail » le 10 Novembre prochain à l’EPITA lors de sa 24ème semaine de Conférences Technologiques.

Le coin de la technique

Benchmarking de Cassandra avec Amazon EC2

Les personnes qui étaient aux derniers ateliers Xebia Tech Event auront remarqué l’utilisation d’Amazon EC2 afin d’équiper les participants en environnements de travail virtuels. Le site Netflix propose un retour d’expérience de l’utilisation d’Amazon EC2 dans le cadre de tests de charge du système NoSQL d’Apache, Cassandra.
La charge est produite par l’outil de stress test distribué fourni avec Cassandra, sur des instances créées sur Amazon EC2.

Les outils développés par Netflix sont capables de créer, en une heure, un cluster comprenant :

• 288 instances de tailles de type M1 Extra Large (m1.xl) réparties sur trois continents;
• 60 instances pour le client de stress test (type m2.4xl) sur un seul continent.

Netflix précise qu’Amazon a mis environ 15 minutes pour créer les 348 instances! Les 45 autres minutes de préparation de l’infrastructure ont été prises par le temps de démarrage de Linux, les JVM des injecteurs, de Cassandra et la création de l’anneau du cluster.
Le test a duré 2 heures, pour un coût total de quelques centaines de dollars. L’avantage mis en avant par Netflix d’utiliser Amazon EC2 est de pouvoir réaliser des tests à très grande échelle, en quelques heures, sans aucun pré-requis matériel ou même impacter l’infrastructure de production. Ce test aurait certainement été plus lent et plus coûteux à organiser dans un datacenter privé d’entreprise.

Netflix a mesuré deux éléments :

• la persistance sur le disque pour l’écriture;
• la performance de cache en mémoire pour la lecture.

Les tests ont été lancés avec 48, puis 96, 144 et enfin 288 instances, avec 10,20,30 et 60 clients. Vous retrouverez dans leur billet les configurations matérielles utilisées lors de ces tests. Un tableau récapitulatif donne une estimation du coût du test de charge entre chaque tir.
Etant donné que les injecteurs de tests étaient sur un continent (Amérique), et les clusters sur trois (Europe, Asie, Amérique), 2/3 du trafic était intercontinental.

Chaque injecteur génère 20 000 requêtes par seconde. Le client est connecté à 3 noeuds Cassandra. Le principe du LOCAL QUORUM est ici utilisé (on attend la réponse de N/2 + 1 noeuds pour la confirmation). Le débit d’écriture a atteint 1,1 million d’écritures par seconde sur tout le système. Avec la réplication entre chaque noeud, on arrive à 3,3 million d’écritures par seconde.
Les mesures effectuées prouvent une montée en charge linéaire de 48 à 288 instances sans identifier de goulet d’étranglement. Les mesures unitaires de chaque noeud montrent une activité équivalente, preuve que le cluster distribue correctement la charge.

Cela démontre bien les nouvelles possibilités offertes par les systèmes d’infrastructure sur demande, et les défis que cela nous permet de relever.

Evénements de notre communauté en France et à l’étranger

Velocity Europe à Berlin le 8 et 9 novembre

Velocity Europe organise mardi 8 et mercredi 9 une conférence à Berlin sur le thème Web Performance et Operations.
Les présentations abordent de nombreux sujets passionnants.
Voici quelques unes des sessions sur les performances Web :

• Know Your Engines: How to Make Your JavaScript Fast
• Mobile UI Performance
• Performance Automation 101

Et sur les operations :

• Be Fast Or Stay Behind – Building A Continuous Delivery Platform
• HTTP Connection Management, From 10 Users To 100 million
• NoSQL Performance In The Real World

Des keynotes auront également lieu avec des speakers venus de Google, Amazon, Dynatrace, New Relic, etc.
Il est important de préciser que certaines présentations sont retransmises en direct, mais pas forcément celles qu’on voudrait .

Nous avons profité du passage en Europe de Jyoti Bansal pour organiser avec les équipes d’AppDynamics un événement autour du monitoring de la « vraie vie » .

A l’heure où l’architecture des applications d’entreprise devient de plus en plus complexe et distribuée, l’outillage dans le domaine du monitoring et du troubleshooting est un élément clé du système d’information. Notre objectif est que chacun en retire des idées immédiatement applicables et se forge une vision des problématiques que les systèmes de monitoring gèrent aujourd’hui et traiteront demain.

Après avoir consulté des Dev et des Ops des secteurs Telcos, Finance, Retail et Voyage, nous avons établi un programme reprenant des cas de notre vie quotidienne illustrés dans une application transactionnelle de eCommerce « réaliste » (1) que nous avons déployée en cluster sur 5 serveurs Amazon EC2., que nous soumettrons à diverses déconvenues courantes.

Programme

• 15 minutes de présentation de la nouvelle génération de systèmes de monitoring d’applications Java (AppDynamics, dynaTrace, JXInsight)
• 60 minutes de démonstration de cas concrets de monitoring :
  • Installation et configuration : mise en place du monitoring, auto découverte, déclaration d’indicateurs applicatifs, ajout de nouveaux serveurs au cluster,
  • Mise en place de tableaux de bord pour les équipes d’exploitation mais aussi de marketing et de développement,
  • Monitoring durant les situations de crise : tableaux de bord « sur mesure » temporaires pour le management, le marketing et les équipes de troubleshooting,
  • Monitoring au service du marketing : nous simulerons la mise en place de la sécurisation 3-D Secure des paiements carte bleue en mode A/B Testing,
• La place dans l’infrastructure du système de monitoring : synergies et chevauchement avec les serveurs d’application, les systèmes de gestion de logs, etc
• La vision de Jyoti Bansal sur les tendances du monitoring d’application, ce à quoi nous devons nous attendre
• Les internes des systèmes de monitoring de nouvelles génération :
  • « java agent embarqué » versus « agent autonome » versus « sans agent »,
  • les tableaux de bords, comment faciliter leur développement et leur utilisation à l’heure des widgets Open Social ?
  • scalabilité des systèmes de monitoring à l’heure où le nombre de serveurs s’envole.
• Coktail avec Jyoti et son équipe.

N’hésitez pas à nous proposer des questions ou des cas d’utilisation que nous ajouterons à nos préparations (cleclerc@xebia.fr et plopez@xebia.fr).

Bio

Jyoti Bansal est fondateur, CEO et CTO d’AppDynamics. Il a auparavant été Principal Architect de Wily Introscope.

AppDynamics a été fondé en 2008. Cette solution de monitoring est utilisée par des clients de la génération Internet aux infrastructures avant-gardistes comme NetFlix (1700 JVM sur Amazon EC2) mais aussi des clients plus traditionnels comme l’opérateur télécoms Swisscom, l’assureur Provinzial Insurance ou l’agence de voyage Priceline.com.

Organisation de la soirée

La soirée se déroulera dans les locaux de Xebia au 156, boulevard Haussmann, 75008 Paris, à partir de 19h00.
Les inscriptions peuvent se faire :

• Par mail : info@xebia-training.fr
• Par téléphone : 01.53.89.99.93

(1) Nous avons retenu Spring Travel enrichie par les Spring Payment Services et une brique « Anti Fraude » pour montrer les appels inter applications java. Le code source est disponible sous licence Apache ici .

Outils

• Helios, Eclipse 3.6

SOA

• Tomcat Stats: administrer Tomcat depuis son iPhone

Le coin de la technique

• Articles sur Groovy/Spring et Grails/Hibernate
• Un nouveau top 10 orienté performance

Agilité

• Happy birthday Post-It !

Outils

Helios, Eclipse 3.6

Après avoir épuisé les principales lunes de Jupiter (Callisto, Europa, Ganymède, Galileo), voici venu le tour d’Helios pour incarner la version annuelle d’Eclipse. Cette livraison ne contient pas moins de 39 projets de la fondation Eclipse et les supports pour Windows7, Ubuntu 10.04 et PowerPC 64 bit ont été ajoutés.

Pour ceux qui aiment ajouter une multitude de plugins à leur Eclipse, au lieu de passer par le « Install new software… », un lien direct vers le Marketplace permet très facilement d’installer ces plugins, un peu à la manière d’un plugin Firefox (tout comme le redémarrage obligatoire). L’ancienne méthode marche toujours pour les applications qui ne se trouvent pas sur le Marketplace. Et sûrement que les fans de DVCS (Distributed Version Control System) vont se précipiter sur le plugin EGit/JGit pour gérer ses sources sous Git, JGit étant l’implémentation full java utilisée également sur d’autre projets alors qu’EGit est sa surcouche pour Eclipse. Le résultat est assez prometteur.

En ce qui concerne uniquement Java, quelques petites améliorations ont été apportées:

• Les options du formatter acceptent plus de sémantiques comme les annotations, la déclaration de méthodes ou la possibilité de désactiver le formatter d’une partie du code (intéressant pour aider des merges compliqués).
• Les fonctionnalités sur le breakpoint, comme l’ajout d’une condition ou le compteur, sont à présent directement accessibles dans le panel breakpoints et non plus en passant par un menu contextuel dans le code.

La version 3.7 devrait surtout se concentrer sur Java7. Ian Bull d’Eclipse propose un top ten intéressant pour faire le tour des fonctionnalités. Arrive en tête l’application Xtext qui permet d’écrire son propre DSL puis de générer à partir de celui-ci son propre éditeur Eclipse contenant la complétion et différents outils pour coder dans ce nouveau langage. Une affaire à suivre.

Mais malgré toutes les nouvelles fonctionnalités, Helios sera surtout scruté pour les multiples bugs corrigés, sa gourmandise en RAM et sa stabilité, ce que seule une pratique intensive pourra valider. Alors à vos souris !

SOA

Tomcat Stats: administrer Tomcat depuis son iPhone

MuleSoft, plus connu pour son ESB Open Source Mule, a récemment annoncé la sortie de Tomcat Stats, la première application de monitoring Tomcat pour iPhone. Cette application gratuite vient enrichir l’offre de support également gratuite, proposée par MuleSoft depuis maintenant presque une année. L’application permet à un administrateur de gérer à distance plusieurs instances de Tomcat, qu’elles soient installées au sein de l’infrastructure propre de l’entreprise ou dans le Cloud. L’ensemble des informations critiques des serveurs administrés pourra alors être consulté depuis l’application, notamment l’utilisation mémoire, les statistiques sur le traffic Web, ainsi que le statut du serveur.

Pour télécharger l’application, rien de plus simple il suffit de se rendre sur l’App Store, directement depuis son mobile, ou sur iTunes à l’adresse suivante : Tomcat Stats By MuleSoft Inc.

Bien qu’un peu gadget, et pas vraiment indispensable, cette application iPhone offrira toujours aux administrateurs la possibilité de prolonger leur pause café sans avoir à culpabiliser.

Le coin de la technique

Articles sur Groovy/Spring et Grails/Hibernate

IBM developerWorks nous a récemment gratifié d’un article en 2 parties intitulé « GroovierSpring ». Dans la première partie, nous apprenons à définir des beans Spring en Groovy. Quatre méthodes sont à notre disposition:

• Utilisation de classes Groovy compilées en .class normaux
• Utilisation de classes Groovy directement sous forme de .groovy
• Utilisation de scripts Groovy en ligne, écrits dans la configuration Spring
• Utilisation de Bean Builder de Grails

Cette dernière possibilité permet de créer des beans dynamiquement, à partir de code Groovy. Cela sous entend que l’on peut, par le code, adapter les beans obtenus selon le contexte, les créer en utilisant des boucles, de la logique… C’est d’ailleurs une solution utilisée dans Grails.

Une fois les beans correctement définis, nous pouvons les utiliser comme n’importe quel bean Java défini plus classiquement. Le fait que les beans soient à l’origine en Groovy est complètement transparent à l’application.
La seconde partie de l’article va plus loin en explorant le rechargement à chaud des beans Groovy. C’est une plus-value importante: qui n’a jamais rêvé de pouvoir changer facilement certains bouts de code soumis aux désirs changeants des clients (ou à des bugs récurrents !) ? De plus, l’article propose une implémentation permettant de stocker son code Groovy en base de donnée, car il n’est pas toujours évident d’accéder au système de fichier des applications en production. C’est une idée assez peu conventionnelle ! D’ailleurs, le paragraphe de fin, intitulé « When Groovy scripts go bad », constitue une mise en garde pour ne pas abuser de ces possibilités, et être conscient des problèmes de sécurité soulevés.

Tant que nous somme dans le monde de Groovy, il nous semble intéressant de vous indiquer un article du blog de SpringSource qui s’intitule « GORM Gotchas (Part 1) ». Il pointe du doigt des comportements de GORM (la couche de persistance de Grails basée sur Hibernate) pouvant sembler bizarres. Les habitués d’Hibernate n’apprendront pas grand choses, mais l’article éclairera sans doutes ceux qui, attirés par la simplicité de Grails, se sont mis à l’utiliser sans expérience préalable d’Hibernate. Ils comprendront ainsi pourquoi leurs objets ne sont pas toujours sauvegardés immédiatement malgré un appel à « save() », et pourquoi ils le sont parfois en l’absence d’appel à cette même méthode. Un autre article traitant de Grails et Hibernate nous vient de Ted Naleid. Celui-ci explique comment il a pu améliorer les performances de son batch en flushant la session Hibernate et en vidant une Map de validation utilisée par Grails en interne. Ces 2 opérations exécutées régulièrement au cours du batch lui ont permis de démultiplier les performances. Grails s’appuie sur Hibernate, et il est parfois bon de se remémorer le fonctionnement de celui-ci pour expliquer et remédier à des problèmes observés coté Grails !

Un nouveau top 10 orienté performance

Ce top10 se trouve sur le blog de l’éditeur Dynatrace. A travers ce que ses consultants ont pu voir chez leur client (on parle donc d’un top 10 sélectif, chez des clients qui avaient conscience d’avoir des problèmes et qui pouvaient se permettre de les diagnostiquer avec un outil comme Dynatrace), il dresse un panorama qu’il est bon de toujours avoir à l’esprit durant nos développements. Nous nous sommes permis de le compléter avec nos propres retours d’expérience.

• une base de données trop sollicitée, ce qui inclut des données requetées trop grandes, ou requetées plusieurs fois, ou encore de trop nombreuses requêtes pour rapatrier une seule donnée (problème des mauvais usage des ORM).
• une mauvaise programmation concurrente, avec un excès de synchronisation.
• un manque de compréhension des appels remote et donc un trop grand nombre d’appels.
• un mauvais usage des frameworks de mapping objet – relationnel. Ce point est largement répandu chez nos clients, en couvrant un large spectre, du simple problème de paramétrage à l’utilisation la plus hors de propos de la librairie.
• l’existence de fuite mémoire (mais pourquoi ce point n’a t’il pas été placé en premier ?)
• une librairie tierce coupable de mauvaises performance. Avec la multiplication des composants dans nos applications, le risque d’introduire des librairies moins robustes et moins performantes existe. Nous avons toujours trouvé étonnant de voir partir en production certains projets basés sur des librairies en béta…
• une mauvaise utilisation des ressources machine (CPU, I/O…). Un traitement prend 50 % de CPU pendant 2 ms. Pas de quoi fouetter un chat ? Multipliez le par 1000 utilisateurs, une consommation mémoire excessive entraînant de fréquents GC, et nous en reparlerons.
• des sites web trop chargés. La bande passante ne cesse d’augmenter, mais ce n’est pas une raison pour surcharger vos frontaux avec de nombreuses images trop volumineuses, des appels AJAX incessants, en ignorant joyeusement les stratégies de cache navigateur et/ou serveur.
• une mauvaise gestion de caching des objets en mémoire. Surchargez votre mémoire pour alléger votre base, et c’est le Garbage Collector qui vous rappellera à l’ordre.
• la sérialisation coute cher. Attention donc, si vous multipliez les appels RMI ou SOAP, à ne pas sérialiser trop d’objets, ou des objets trop volumineux.

Nous avons échangé les places du point n°10 et du point bonus. Le point n°10, même si il a une réalité tangible, nous paraissait un peu trop marketing (mais c’est en partie la raison de vivre d’un blog éditeur) et nous préférons le déplacer en bonus :

• le problème intermittent, invisible. C’est celui dont il faut se prémunir en multipliant les tests (fonctionnels, de charge) ou en étant idéalement outillé.

Agilité

Happy birthday Post-It !

Et pour conclure cette revue de presse, nous ne résistons pas à l’envie de partager avec vous cette nouvelle d’importance: les Post-It, ces fameuses petites notes collantes multicolores, fêtent leurs 30 ans. Rappelons que l’utilisation de Post-It est devenue partie intégrante de la pratique de Scrum. Comment mettre à jour facilement la liste des tâche d’un Sprint sans Post-It ?! Alors pour leur rendre hommage, regardons quelques photos ou encore cette magnifique vidéo de laquelle ils sont les acteurs majeurs. Bon anniversaire les p’tits gars !

Actualité éditeurs / SSII

• Où sont passées les stars de Sun ?

Le coin de la technique

• Nouvelle version pour EhCache
• jucProfiler
• Maven Enforcer

Actualité éditeurs / SSII

Où sont passées les stars de Sun ?

Un an après le rachat de Sun par Oracle, qu’est il advenu des stars de Sun ? La réponse est plutôt radicale : elles se sont envolées vers des cieux plus cléments. Avant d’entrer dans plus de détails, on peut d’abord noter que la différence « génétique » entre Sun, moteur d’innovation proche d’une entreprise de recherche, et Oracle, éditeur logiciel centré sur le business, augurait de nombreux chocs culturels.
Certains ont été violents, et la rupture a été amère. C’est le cas pour James Gosling, qui a été le plus prolixe (sur son blog) au sujet de son départ, évoquant une démission qui l’a occupé à plein temps pendant plusieurs semaines. De manière comparable, Tim Bray a rejoint Google, en ne détaillant pas les raisons qui l’ont poussées à quitter Oracle mais en laissant transparaître une certaine amertume.
D’autres sont partis car Oracle ne leur donnait pas de garanties sur leur technologie : Charles Nutter et Thomas Enebo ont rejoint Engine Yard pour continuer à développer JRuby. Kohsuke Kawaguchi a monté sa société pour porter Hudson.
Enfin, certains n’ont pas reçu d’offre d’Oracle. C’était attendu pour Jonathan Schwartz et Scott McNealy qui étaient quasiment condamnés par leur position au sommet de la hiérarchie de Sun. C’était plus surprenant pour Simon Phipps, responsable de l’open source, qui occupe un poste équivalent chez ForgeRock (qui entend développer -OpenSSO- pardon OpenAM, le nom OpenSSO étant déposé).
Alors, cette vague de départs sera t’elle préjudiciable à Oracle ? Sur le plan de l’innovation, certainement. Sur un plan purement business, on peut en douter, aucun des « sous »-produits (sans que nous portions de jugement de qualité) de Sun n’étant stratégiques pour la firme de Larry Ellison. D’ailleurs, si l’on jette rapidement un œil à ceux qui sont restés, on note John Fowler, Cindy Reese, et Mike Splain, tous trois impliqués dans la branche hardware. De là à dire que c’était la principale visée d’Oracle (avec la JVM)… « Malheureusement », Oracle a aussi hérité de bébés bien encombrants, comme les JUG (voir l’article de Nicolas de Loof à ce sujet).

Via infoWorld

Le coin de la technique

Nouvelle version pour EhCache

Terracotta maintient le rythme des évolutions Ehcache, en nous livrant cette nouvelle version numérotée 2.1.
Après un mois de maturation en bêta, l’éditeur officialise donc la dernière mouture stable de son célèbre cache.
C’est surtout l’occasion d’étoffer son offre produit en ajoutant notamment un plugin de monitoring permettant de surveiller en temps réel les métriques essentielles du cache. Grâce à lui, les développeurs pourront affiner la configuration du cache, par contre pour l’utiliser en production il vous faudra une version payante.
Le support Websphere a bénéficié lui aussi d’améliorations pour garantir à ses utilisateurs l’accès à toutes les fonctionnalités du produit.
Cela inclut tout naturellement, le support la solution Terracotta Web Session, un cluster de session web à haute disponibilité, déjà disponible pour Weblogic, JBoss, Tomcat et Jetty.
L’utilisation de JTA a aussi été largement améliorée, les configurations standalone et Hibernate sont à présent supportées, ce qui permet de couvrir l’intégralité des stratégies Hibernate.
En dernier point d’amélioration, le développement a été axé vers de meilleures performances et un paramétrage fin des SLAs. C’est par exemple la fonctionnalité NonStopCache qui permet de contrôler le timeout des opérations sur le cache, voire même de passer automatiquement d’un cache sur disque à un cache en mémoire vive en cas d’indisponibilité. Par ailleurs le UnlockedReadsView offre une vue non consistante du cache. Dans les faits, elle ignore les verrous d’écriture et ne pose pas de verrou de lecture, l’équivalent d’un READ_UNCOMITTED avec des performances très largement accrues.

• L’annonce Terracotta
• Un article plus poussé par Steve Harris
• La page d’accueil du projet

jucProfiler

Il y a quelques années, certains se sont arrachés les cheveux pour détecter les contentions dans un programme massivement parallélisé. Malheureusement pour les amoureux des nœuds au cerveau, les développeurs de chez IBM se sont penchés sur le sujet et proposent un outil pour diagnostiquer ce type de problèmes : jucProfiler (pour java.util.concurrent). Le principe est simple : instrumenter le bytecode de certaines classes de java.util.concurrent.locks et tracer les appels à java.util.concurrent.locks.LockSupport et java.util.concurrent.locks.AbstractQueuedSynchronizer.
L’outil génère ensuite un rapport permettant d’identifier deux types de problèmes sur les thread, consomateurs de temps :

• du temps de contention : un verrou est réservé par un autre thread.
• du temps d’attente : le thread est en wait.

Et cerise sur le gâteau, pour ceux d’entre vous lassés de devoir diagnostiquer des problèmes de performances en analysant des fichiers texte de trois pieds de long, un éditeur graphique est même fourni.

Comme le dit justement la conclusion de l’article, la généralisation de la programmation parallèle nous oblige à nous armer de meilleurs outils. Il semblerait que jucProfiler en fasse partie. Si l’un de nos lecteurs a eu l’opportunité de l’utiliser en condition réelle, nous sommes bien sûr preneurs d’un retour d’expérience.

Maven Enforcer

Sonatype a récemment mis en ligne une présentation en deux parties (ici et là) sur le plugin Maven Enforcer.
Ce plugin permet de définir des règles afin d’obtenir un build Maven reproductible sur différents environnements. Il permet entre autres :

• de spécifier une version ou une plage de versions de Maven,
• de spécifier une version ou une plage de versions du JDK,
• de spécifier une architecture (OS/CPU) sur laquelle s’exécute le build,
• de s’assurer que le projet ne contient pas de dépendances (transitives) vers des versions non explicites (SNAPSHOT, LATEST ou RELEASE),
• de s’assurer que le projet n’utilise pas de plugins ayant une version non explicite (SNAPSHOT, LATEST ou RELEASE),
• de bannir des dépendances,
• de définir ses propres règles (en Java ou avec un script BeanShell).

La présentation met l’accent sur la nécessité de fixer les versions des dépendances et des plugins afin d’éviter qu’un build ne devienne instable suite à la publication d’une nouvelle version d’une dépendance ou d’un plugin. Il préconise notamment l’emploi de Maven en version supérieure à 2.0.9 pour laquelle le POM parent n’utilise plus que des versions explicites des plugins.

Elle recommande aussi de spécifier une version du JDK (1.5.x par exemple) afin d’éviter différentes problématiques telles que l’utilisation d’API non supportées ou la différence de comportement de certains plugins Maven en fonction de la version de la JVM sur laquelle ils sont exécutés.

Une fois les bonnes pratiques exposées, la configuration des différentes règles permettant d’effectuer les vérifications est abordée.

Le plugin Maven Enforcer est encore peu connu mais gagnerait à être utilisé pour éviter des problèmes récurrents. Cette présentation est un bon point de départ pour aborder sa mise en place.

Cette formation approfondie de 4 jours vous permettra d’obtenir les compétences nécessaires pour optimiser la performance de vos applications Java. Vous aborderez pendant cette formation tous les aspects de la performance : l’outillage nécessaire, les méthodologies à appliquer, les concepts d’architecture sous jacents à la performance, les meilleures pratiques, le benchmarking et la gestion de mémoire.

A l’issue de cette formation, vous serez en mesure :

• D’identifier rapidement et régler les problèmes de performance de vos applications.
• D’identifier et résoudre des problèmes de fuite mémoire en quelques heures.
• D’isoler des problèmes classiques et d’éviter de s’engager dans des plans d’actions couteux et inefficaces.
• D’identifier des problèmes de performance avant qu’ils ne deviennent critiques pour les applications.

Les stagiaires bénéficieront des Tips de Kirk Pepperdine, référence reconnue dans le monde de l’optimisation de performance objet.
Kirk Pepperdine dispose de 15 ans d’expérience dans les technologies OO et l’optimisation de la performance. Figure emblématique du monde Java et élu « Champion JAVA » en 2005, Kirk est reconnu comme le référent de l’optimisation de performance Java.
Vous pouvez consulter le programme complet de cette formation en consultant notre site : http://training.xebia.fr/formation-java-performance-tuning-kirk-pepperdine/.

• Le catalogue numérique.
• Le catalogue PDF.

Xebia Training se positionne logiquement dans la continuité de Xebia, tant sur la qualité de son offre de formation technique que méthodologique (méthodes agiles), en proposant des formations haut de gamme animées uniquement par les référents de leur domaine.

Avec pour principe premier le refus de tout compromis sur la qualité du formateur et du contenu, Xebia Training fait systématiquement intervenir des acteurs de références dans leurs domaines respectifs.

Nos formations, savant équilibre entre théorie et travaux pratiques, sont destinées à un large public soucieux d’acquérir les meilleures pratiques de notre industrie.

Le premier XKE dans nos nouveaux locaux a donné lieu à de bien curieuses scènes : des bisounours ont hué des poubelles sous le regard moqueur de pokemons ! Et, non, les cartons de déménagement ne nous sont pas tombés sur la tête. Ce n’était là que quelques uns des noms choisis par des équipes de 3 à 4 consultants, qui se sont mesurés dans un concours de tuning de performance, sur une application Java EE standard, buggée (volontairement, pour une fois) par les maîtres de cérémonie, Guillaume Bodet et Cyrille Le Clerc. Tous les participants se sont vus remettre une VM, contenant un Tomcat, une application (PetClinic de Spring, revue et « corrigée ») et des scripts de performance JMeter. Le code source n’a, dans un premier temps, pas été fourni.

Pour tous, un seul but : faire diminuer les temps de réponses de l’application.

Les règles étaient les suivantes :

• Un bug n’est considéré comme trouvé que lorsqu’il a été identifié, qu’un correctif a été proposé et que la preuve est faite que ce correctif permet d’améliorer significativement les temps de réponse.
• Il existe trois niveaux de difficulté, allant du bug évident à l’anomalie la plus fourbe.
• Le choix des outils est libre.

A vos marques… Prêts ? Débuggez !

Préambule

L’un des buts de ce Xke était d’être très didactique, dans les méthodes de recherche et dans l’utilisation des outils. Les bombes placées dans le code permettaient de réaliser une progression linéaire (dans la difficulté comme dans les gains attendus). Cette progression est retranscrite dans cet article et ceux qui vont suivre.

Cependant, pour différentes raisons que nous aurons l’occasion d’expliquer, l’ordre des analyses, et donc de découvertes des bugs, n’est pas celui qu’aurait choisi un champion de la performance, j’ai nommé Kirk Pepperdine. Nous lui avons soumis notre application, et nous vous exposerons sa méthode d’analyse et les raisons qui la motivent dans le dernier article de la série.

Premier contact avec l’application…

Ouverture du navigateur, entrée de l’url, et, pas de surprise, l’application PetClinic s’ouvre.

Premier lancement de JMeter, et première constatation : avec un seul utilisateur, l’application met en moyenne plus de 2 secondes à répondre. Inacceptable pour la plupart des sites web (surtout avec un seul utilisateur actif).

… et premiers réglages

A première vue, la machine ne semble pas à genoux, on peut donc incriminer directement l’application.
Nous allons donc chercher à savoir ce qu’elle fait. Un réflexe classique, qu’un certain nombre d’entre nous a eu, est d’aller ouvrir les logs. Catalina.out est vide, on n’a pas de répertoire de logs applicatives évident, à priori le coupable classique, la configuration log4j, est à écarter. Et pourtant… Pour savoir ce que fait réellement notre application, il est possible de réaliser une série de thread dumps. Pour cela, deux possibilités :

• la vieille école, qui va dumper le contenu des threads à l’aide d’un kill -3 sur la jvm.
• l’école moderne, qui va utiliser JVisualVm (et ses plugins) pour réaliser la même opération à l’aide d’une belle interface.

Et là, demie surprise, notre thread actif est souvent surpris dans la méthode org.apache.log4j.spi.LoggingEvent.getLocationInformation. Nous aurions donc un logger actif. Nos soupçons initiaux se confirment, ne reste plus qu’à débusquer le coupable.
Nous n’avons pas (encore) le code source. Or, cette bombe plombe tellement l’application qu’il n’est pas envisageable que nous ne puissions pas la résoudre de suite. On doit donc avoir un fichier de paramétrage de la log externalisé. Là encore, VisualVm va nous aider. Dans la fenêtre overview, les paramètres de démarrage de la VM sont affichés. Et l’on voit apparaitre une directive de configuration log4j, -Dlog4j.configuration.

Un petit grep dans le répertoire de lancement de Tomcat ($TOMCAT_HOME/bin), et nous voyons apparaître dans le setEnv.sh la ligne -Dlog4j.configuration=file:$CATALINA_HOME/conf/log.xml. Et si nous ouvrons ce fichier, le root Logger est bien en DEBUG. Mais aucune directive spécifique pour logger ailleurs que dans la console. Tout devrait donc aller dans catalina.out. Ca sent la redirection ‘sauvage’. Continuons à parcourir les fichiers de lancement. Un petit tour dans catalina.sh, et surprise, une belle redirection Unix "$CATALINA_BASE"/logs/catalina.out 1> /var/log/catalina/tomcat.log &
Et en ouvrant ce fichier, on comprend mieux le temps perdu : des milliers de lignes de debug !

Celles ci ont d’ailleurs une particularité sympathique : à chaque ligne de debug, le numero de ligne de la classa Java est indiqué.
C’est pratique ! Pourquoi ne met on pas systématiquement en place cette configuration sur nos projets ?
Un petit tour dans la documentation Log4J nous apprend :

Log4J nous prévient, ces méthodes sont sous performantes. Si l’on creuse un peu dans le source, on trouve la classe affichant les pattern %M et %L, org.apache.log4j.spi.LocationInfo, qui contient le constructeur suivant :

public LocationInfo(Throwable t, String fqnOfCallingClass) {
if(t == null || fqnOfCallingClass == null)
return;
String s;
// Protect against multiple access to sw.
synchronized(sw) {
t.printStackTrace(pw);
s = sw.toString();
sw.getBuffer().setLength(0);
}
[...]

Autrement dit, pour chaque ligne de log, Log4J génère une stackTrace pour pouvoir récupérer le numéro de la ligne et le nom de la méthode. Pas vraiment performant.
Modifions donc le pattern et observons le résultat.

• Suppression de %M:%L dans le pattern du Logger
• Temps moyen de 2,3 s à 2,0 s pour 1 utilisateur
• 2 points pour l’équipe qui a trouvé

Toujours concernant ce fichier de log, nous voyons apparaître une ligne ne respectant pas le PatternLayout de Log4J, préfixée par Hibernate, qui trace une requête SQL. Gardons cette ligne en mémoire, nous y repenserons quand nous aurons le code source.

Deuxième amélioration immédiate envisageable, une application, qui plus est en production, ne devrait pas avoir besoin d’un niveau de log aussi fin. Passons le donc à ERROR.

• Logger de DEBUG à ERROR
• Temps moyen de 2,0 s à 1,75 s pour 1 utilisateur
• 1 point pour l’équipe qui a trouvé

Nous avons fait un sort au logger. Mais nous n’en avons pas encore fini avec la configuration out-of-the-box de cette application.

Source

Image libre de droits

Pour ceux qui ne le connaissent pas, Kirk Pepperdine dispose de plus de 15 ans d’expérience dans les technologies orientées objets et l’optimisation de la performance. Figure emblématique du monde Java et élu « Champion JAVA » en 2005, Kirk est reconnu comme le référent de l’optimisation de performance Java. Il est le DSI de Kodewerk Ltd et le principal contributeur de javaperformancetuning.com.

Cette formation approfondie de 4 jours permettra aux stagiaires d’obtenir les compétences nécessaires pour optimiser la performance de leurs applications Java/J2EE. Vous aborderez pendant cette formation tous les aspects de la performance :

• L’outillage nécessaire.
• Les méthodologies à appliquer.
• Les concepts d’architecture sous jacents à la performance.
• Les meilleures pratiques.
• Le benchmarking.
• La gestion de mémoire.

Si cette formation vous intéresse, n’hésitez pas à contacter Roderic Pratt au 06.09.69.05.49.

Le coin de la technique

• invokedynamic vu de l’intérieur
• Concurrency : past and present
• Tuning des JVM Websphere 6.1
• Performance d’affichage d’une page Web

Evènements de notre communauté en France et à l’étranger

• Refactoring itératif de conférences : JavaPolis, Javoxx et DeVox

Le coin de la technique

invokedynamic vu de l’intérieur

Dans cet article, Charles Nutter, JRuby Core Developper nous présente pourquoi il est nécessaire de mettre à jour le bytecode invokedynamic.
Java nous oblige à typer chaque variable et chaque méthode doit définir une signature statique dont les types sont connus avant le Runtime : Java est un langage ‘statiquement’ typé. Si ce typage fort est une des forces du langage, comment la JVM peut-elle supporter des langages dynamiques ? La rigidité de Java provient, plus de son langage que de son bytecode. C’est ainsi que des langages comme Groovy permettent d’enfreindre certaines règles, par exemple : ne pas définir de types aux variables. Ce n’est pas pour autant que le bytecode va tout nous permettre, certaines règles sont incassables dont celles qui s’appliquent aux invocations de méthodes :

• Les invocations sont statiquement typées.
• Les invocations doivent s’effectuer sur des méthodes Java. Il est impossible de remplacer un appel à une méthode par un morceau de code interprété.

À l’origine, la JSR-292 a proposé la mise en place d’un nouveau code invokedynamic permettant l’invocation de méthodes sans signatures typées statiquement, mais rien n’avait été prévu pour modifier dynamiquement la logique d’invocation de la JVM.

Concurrency : past and present

Brian Goetz, auteur du livre ‘Java Concurrency In Practice’, a publié sur InfoQ une vidéo enregistrée lors du QCon 2007 : Concurrency : Past and Present.
Pourquoi est-il plus difficile de développer des applications multithreadées que de parler en lisant son journal ?
Dans cette présentation, Brian tente de répondre à cette question en revenant sur les principales difficultés de la programmation concurrente. Sujet que nous avions également abordé lors d’un article publié cet été sur le sujet : « programmation concurrente : notions fondamentales« . Pour illustrer ces problèmes, Brian revient sur l’histoire de la programmation concurrente et ses différentes approches, avant de donner ses recommandations. À la fin de la vidéo, il présente également les fonctionnalités offertes par d’autres langages comme ErLang et Scala.

Tuning des JVM Websphere 6.1

Giribabu Paramkusham et Ajay Bhalodia, WebSphere Application Server Technical Support, présentent dans JVM Performance Tuning with respect to Garbage Collection(GC) policies for WebSphere Application Server V6.1 part 1 (pdf) les points clef du tuning des JVM pour Websphere. Nous retiendrons :

• Les JVM IBM proposent quatre stratégies de garbage collections :
       - -Xgcpolicy:optthruput pour minimiser le temps global d’exécution (batch, …).
       - -Xgcpolicy:optavgpause pour minimiser la durée de chaque pause.
       - -Xgcpolicy:gencon destiné aux applications web. L’algorithme Générationnel Concurrent communément utilisé dans les JVM Sun est optimisé pour les objets à courte durée de vie.
       - -Xgcpolicy:subpools pour les serveurs à grand nombre de processeurs (>16).
• A la différence de l’implémentation GenCon de Sun qui comprend trois zones (Young, Tenurd et Permanent), celle d’IBM n’en comporte que deux (Young et Old)
• L’option -verbose:gc est activable en production avec un impact négligeable sur les performances et l’option moins connue -Xverbosegclog permet de préciser un fichier de sortie en mode rolling file . Nous noterons que les informations de GC sont désormais formattées en XML ce qui facilitera la manipulation avec des outils.
• Indépendamment des limites techniques liées au système d’exploitation, les JVM IBM sont optimisées pour utiliser des heap le plus souvent inférieures à 2 GB :

source IBM

• L’utilisation de JVM 64 bits supprime les limites de taille de heap mais pénalisent les performances (plus de données manipulées) et la consommation mémoire (des pointeurs sur 64bits plutôt que 32bits accroissent de 30% à 50% la mémoire consommée)
• La JVM 6 d’IBM réduit les dégradations de performances et de consommation mémoire en 64bits grâce à l’introduction de « pointeurs compressés »

Performance d’affichage d’une page Web

Hayes Potter, nous présente dans Speed up your website, quick! des règles structurantes afin d’améliorer les performances d’affichage d’une page Web :

• Compression des ressources statiques (images, fichiers flashs, scripts, …).
• Mettre en place une politique d’expiration des ressources statiques .
• Mettre les styles CSS en haut de la page HTML tandis qu’il faut mettre les fichiers Javascript en bas de la page.
• Limiter les requêtes http://request vers d’autres domaines. En effet à chaque requête vers un autre domaine, pendant le chargement de la page, une résolution DNS est effectué (accès réseaux supplémentaires).

Dans le même esprit, Yahoo a mis à dispositon de la communauté des développeurs Web un ensemble de règles : Exceptional Performances.
Il y a 34 Best Pratices répartis dans 7 domaines différents :

• Contenu
• Serveur
• Cookie
• CSS
• Javascript
• Image
• Mobile

Voici les règles les plus marquantes :

• Externaliser les fichiers CSS et Javascripts de la page HTML.
• Réduire la taille des fichiers Javascripts en éliminant les caractères superflus (espace, variable à rallonge, …). Cela peut être assisté par des outils tel que JSMin et YUI Compressor. L’idéal c’est que les développeurs des pages gardent des fichiers Javascripts lisibles et maintenables puis au déploiement de ces pages, passer une moulinette sur les fichiers Javascripts afin d’épurer les caractères superflus.
• Eviter la duplication des importations du même script, par exemple IE retéléchargera plusieurs le fichier bien que c’est la même ressource.
• Utiliser une requête HTTP GET pour les requêtes AJAX.
• Rassembler l’ensemble de vos images (pour les gestions des boutons par exemple) en une seule image et en faire un sprite avec CSS. Cette tache peut être assister par les outils CSS Sprites et Website Performance CSS Sprite Generator.
• Limiter l’utilisation des iframe.

Références :

• Yahoo! New Performance Best Practices Now Available (Mars 2008), excellente présentation de Stoyan Stefanox, développeur Yahoo, qui reprend point par point toutes ces Best Pratices

Voici une liste d’outils facilitant la mise en oeuvre et la vérification de ces points :

• YSlow, outil Yahoo aidant à la vérification de ces best pratices
• Fiddler, debugger HTTP
• IBM Page Detailler, décrire le déroulement des fichiers téléchargés pour l’affichage d’une page
• Firebug (que pour firefox)
• JSMin, minimiseur JavaScript
• YUI Compressor, minimiseur Javascript
• CSS Sprites, générateur de sprite CSS
• Website Performance CSS Sprite Generator, générateur de sprite CSS

Evènements de notre communauté en France et à l’étranger

Refactoring itératif de conférences : JavaPolis, Javoxx et DeVox

Terminons cette revue de presse par la petite histoire belge de la semaine. L’un des plus gros événements Java au monde JavaPolis vient de changer de nom pour la seconde fois cette année. Renommé Javoox en début d’année, il semblerait que cet ancien nouveau nom soit encore trop proche de « Java » pour Sun. Avec ce nouveau nom : DeVoxx, le BeJug (porteur de l’événement) continue le bras de fer avec Sun en osant mettre un ‘V’ en 3e caractère de leur nouveau nom … tout comme dans ‘jaVa’ … La newsletter de DeVoxx nous explique que ce nouveau changement de nom est dû à une volonté de rester un événement Java indépendant.

• Site officiel du BeJug
• Site officiel du DeVoxx
• Consultez la liste des intervenants à DeVoxx 2008

Actualité éditeurs / SSII

• Projet Cassandra : donation de Facebook à la communauté Open Source

Agilité

• Les outils pour l’Agilité

RIA

• OSCON 2008 : Web framework of the future

SOA

• Succès des projets SOA : seulement 20% selon le Burton Group

Le coin de la technique

• Interopérabilité OSGI et Java Module System
• Nouvelle JSR : Post mortem JVM Diagnostics API
• Optimiser les performances de Java : rencontre avec Kirk Pepperdine
• M2Eclipse : Le nouvelle éditeur graphique de pom

Actualité éditeurs / SSII

Projet Cassandra : donation de Facebook à la communauté Open Source

Cassandra est un système distribué de stockage de données. Cette solution sera Open Source.

Cassandra est une solution développée par Facebook (Facebook Data Team), le site de réseau social.

Cassandra s’inspire de l’architecture de Google Big Table et Amazon Dynamo. Ces systèmes sont conçus pour être des solutions fortement scalables et aussi gérer des entrepôts de données importants, de l’ordre du petabyte (représente 10 puissance 15 soit un un million de milliards). Son architecture est semblable à un réseau P2P contrairement ou base de données classique (Oracle, MySQL, …) qui ont une architecture centralisée (sous forme de Cluster). Cette architecture permet de répartir la charge et de contourner des goulets d’étranglement de trafic de données.

L’avantage d’une telle architecture est d’être très scalable, et d’éviter les goulets d’étranglement de performance, au détriment de la cohérence de données.

Autant dire que les problématiques adressées par ces outils sont fortement critiques, mais seulement pour des systèmes d’information très particuliers.

Agilité

Les outils pour l’Agilité

Kent Beck (l’un des fondateurs d’XP) partage ses réflexions sur la relation entre les outils et l’Agilité.

Il constate que beaucoup de personnes font une mauvaise interprétation d’un des principes du manifeste agile : Privilégiez les personnes et leurs interactions plutôt que les processus et les outils. Cela ne signifie pas qu’il n’y a pas besoin d’outil ! Les outils sont indispensables et les méthodes agiles font émerger de nouveaux besoins. Les tests unitaires, la conception incrémentale, et l’intégration continue sont des exemples de changements qui accompagnent le développement agile. Kent prédit d’autres changements à venir :

• Des transitions plus aisées entre les activités
• Un plus grand périmètre pour les tests automatiques
• La transparence
• Une collaboration en temps réel

Une synthèse du livre blanc est disponible sur InfoQ et sur le blog de Claude Audry.

RIA

OSCON 2008 : Web framework of the future

Lors de la convention de l’Open Source à Portland (EU), Matt Raible a présenté Web framework of the future où sont comparés les frameworks suivants : Flex, GWT, GRails et Rails

Il propose deux ‘nouveaux’ pattern pour la conception des couches de présentation pour les applications SOA :

• SOFEA, for Service-Oriented Front-End Architecture.
• SOUI, Does the rise of Service Oriented UI (SOUI) means the death of server-assisted MVC?

Le SOFEA se fonde sur trois principes fondamentaux :

• AD : Application Download, décrit la manière dont la couche client est téléchargée du serveur chez l’utilisateur. Suivant le paramétrage du client (logiciel, sécurité, …) une certaine application sera téléchargée par le client
• PF : Presentation Flow, décrit la manière dont la couche de présentation enchaîne les écrans et dont les données sont transmises d’écran en écran. La réalisation de ce principe doit être dirigée par la partie client et non service
• DI : Data Interchange, décrit la manière dont la couche de présentation et la couche service s’échangent les données. La couche de présentation doit supporter les mêmes structures de données que la couche modèle

La tableau suivant liste quelques solutions pour implémenter les trois principes précédents avec deux modèles de client thin client, rich client :

A l’instar du SOFEA, le SOUI se base sur un découplage net entre la couche de présentation et la couche service métier. La conception de la couche présentation est pilotée par la couche de service métier et non l’inverse.

Ces principes sont mis en oeuvre au travers de 3 frameworks :

• Flex : pour la réalisation d’interface en Flash.
• GWT : pour la réalisation d’interface en DHTML/Ajax, développée en Java. Cette technologie peut amener à des difficultés lors que l’on travaille sur du code source existant.
• GRails (Rails) : pour la réalisation d’interface Web en suivant le pattern MVC. Le scaffolding apporte une mise en place des écrans rapide, mais supporte mal le REST.

Ces technologies sont assez différentes dans leur architecture et dans leur prise en compte de l’existant. Flex supporte bien le REST. Les technologies Rails (GRails, Ruby On Rails, Django) apportent de la productivité grâce à un langage dynamique et expressif, au SOA

Succès des projets SOA : seulement 20% selon le Burton Group

Nous annoncions en Mars dernier le lancement du sondage du Burton Group sur le succès des projets SOA. Nous saluerons d’abord l’honnêteté de l’étude d’Anne Thomas Mannes qui reconnaît pas moins de 50% d’échecs complets.

Il ne faut pas pour autant condamner SOA dans son ensemble ; les piliers de cette démarche correspondent à des réalités des entreprises d’aujourd’hui. Certains principes comme le couplage lâche et la cohérence ne sont pas nouveaux et des idées comme la gouvernance des services et les Service Level Agreement qui vont avec, restent souvent des voeux pieux difficilement mis en oeuvre eu égard aux changements culturels qu’ils demandent.

Nous ne tirerons donc pas aujourd’hui sur l’ambulance. En plus des 10 pièges de la SOA dont nous avons déjà parlé ces dernières semaines, nous retiendrons que sur le fond, les échecs sont plus souvent dûs à un manque de vision métier et architecturale qu’un à problème d’implémentation technique.

Un point intéressant de l’étude du Burton Group : une culture purement projet, malgré ses vertus de mise en production à un prix et une date maitrisés, se marie mal à une démarche SOA. Le délai court et le périmètre étroit, clefs du succès d’un projet (ce que nous prônons), sont souvent incompatibles avec une architecture SOA qui demande une vision plus large des briques du SI et des retours sur investissements plus long.

Le coin de la technique

Interopérabilité OSGI et Java Module System

Plusieurs mois après l’annonce d’une éventuelle interopérabilité entre Java Module System et OSGI, le sujet est toujours en discussion au sein du groupe d’experts de la JSR-277. Sun semble un peu patauger dans la gadoue sur ces spécifications, il est vrai qu’il est difficile de contenter tout le monde sur un sujet ou chacun essaye d’imposer ses idées.

Et bien vous pouvez maintenant vous faire votre propre opinion, le sous-projet implémentant le draft de Java Module System inclus maintenant un repository OSGI. Le prototype est pour le moment uniquement compatible avec l’implémentation OSGI de la fondation Apache (Apache Felix). L’interopérabilité semble complètement transparente à l’utilisation, vous pouvez importer des modules OSGI de la même manière que vous importeriez des modules JAM (JAva Module). Si vous voulez essayer par vous-même un exemple complet est disponible sur le blog de Mandy Chung.

Nouvelle JSR : Post mortem JVM Diagnostics API

Les principaux outils de diagnostic (débuggeur, outils de trace, analyse de performance) permettent de surveiller le comportement de la JVM lorsqu’ils sont activés. Ce genre d’outils est très efficace quand les problèmes sont reproductibles et que le client est prêt à accepter le prix de cette reproduction. C’est pourtant en pratique pas toujours le cas : soit par ce que le bug est dû à un problème ponctuel, soit par ce que le coût de reproduction n’est pas acceptable. L’analyse rétrospective est compliquée et nous manquons d’outils permettant d’effectuer des analyses ‘post-mortem’.

La nouvelle JSR-326 : Post mortem JVM Diagnostics API voudrait pallier à ce manque en proposant un API permettant d’effectuer des analyses sur des artefacts générés à chaud par la JVM (HPROF ou autres… ).

Elle proposera :

• un ensemble d’outils permettant de lire ces analyses
• un moyen d’étendre ces outils
• un moyen de standardiser la génération à la volée de ces artefacts

Alex Miller en a profité pour demander à Steve Poole (specifications leader de la JSR) si celle-ci à une chance d’arriver à temps pour le jdk7. La réponse évidement incertaine : toujours aucune date pour cette fameuse umbrella JSR devant officialiser le contenu de la prochaine version de Java…

Optimiser les performances de Java : rencontre avec Kirk Pepperdine

Dans cet article sur le Sun Developpper Network, Kirk Pepperdine revient sur ses expériences dans le domaine de la performance. Nous retiendrons les points suivants :

• L’un des principaux écueils dans une analyse de performance est le manque de méthode avec un focus prématuré sur le code. La plupart des équipes plongent directement dans le code, au mépris d’informations plus globales sur le système. Pour améliorer ce point Kirk Pepperdine expose deux méthodes : la box et le mantra Ne devinez pas, mesurez
  Plonger directement dans le code est d’ailleurs l’un des soucis majeurs que Kirk Pepperdine a rencontré au cours de sa carrière : aussi doué soit-il, un développeur ne parviendra pas à résoudre un problème de performance uniquement par la lecture du code ; la phase préliminaire de caractérisation du problème et d’identification du code en cause est primordiale.
• L’un des facteurs de succès dans l’amélioration des performances est un code source simple et bien structuré. Un code simple (a.k.a. « dumb ») permet une meilleure analyse, aussi bien par des humains que par les optimiseurs de JVMs. De plus, un code complexe cache souvent des optimisations prématurées.
  Un code bien structuré permet ajouts et remaniements qui sont souvent la clé de toute optimisation.
  De manière générale, les grands principes agiles (couplage lâche, délégation, application des bons design patterns, bonne couverture de tests unitaires, builds automatisés) s’appliquent dans le cadre du tuning des performances.
• Il faut se méfier des Performance Tips qui peuvent se révéler être des faux amis : une solution peut fonctionner dans un cas et s’avérer catastrophique dans une autre situation ou avec les versions suivantes d’une JVM.
• La majorité des problèmes de performances se situent au niveau de la base de données et de la mémoire de la JVM.
  Les principales mauvaises pratiques en ce qui concerne les liens entre programme Java et base de données sont :
       - Rendre son application résistante à l’introduction de caches (e.g. en mélangeant des accès jdbc au code métier)
       - Utiliser la base de données comme un mécanisme de lock distribué
       - Utiliser la base de données pour exécuter de la logique métier clef
       - Stocker des flux dénormalisés en base.
  Le premier indice d’une sur-utilisation de la base est le nombre d’interactions entre celle-ci et l’application. La correction la plus triviale à cette erreur est d’ajouter un cache, ce qui sera beaucoup plus rapide et efficace que de tenter de réduire le nombre d’appels à la base.
  Une autre astuce est de grouper au maximum les interactions application – base de données.
• La gestion de la mémoire peut aujourd’hui reposer uniquement sur des outils efficaces :
       - Détection des fuites mémoire : Visual VM et Netbeans Generation
       - Objets ‘zombis’ : Netbeans Generation ou attendre le time out de ces objets
       - Un taux élévé de création d’objets. Cela entraîne généralement une Garbage Collection inefficace. Surveiller l’activité du GC permet donc de diagnostiquer ces problèmes (HPJMeter, Tagtraum, gchisto).
  La majorité des problèmes de mémoire peuvent être réglés en jouant sur les Java Heap Size.
• Une équipe stressée ne parviendra pas à traiter efficacement les problèmes. C’est pour cela qu’il est parfois bon d’envisager une correction ‘quick & dirty’ qui contente un maximum d’utilisateur, afin de faire baisser la pression sur les développeurs, pour pouvoir se poser et réfléchir à une solution à long terme.

M2Eclipse : Le nouvelle éditeur graphique de pom

Une nouvelle fonctionnalité vient de paraître dans la version 0.9.5 du plugin M2eclipse : l’éditeur graphique de fichier pom.xml. On peut remarquer que pour une première version, l’éditeur est déjà assez complet : la très grande majorité des paramètres configurables d’un pom sont présents et l’éditeur offre la complétion pour l’ajout de dépendances (déjà présent dans l’éditeur « source »).

Mais la fonctionnalité qui mérite le coup d’oeil est celle permettant d’afficher l’arbre de dépendance sous la forme d’un arbre. L’éditeur reprend le goal tree du maven-dependency-plugin en lui ajoutant la visualisation graphique qui le rend bien plus facile à utiliser que son rendu en ligne de commande. Pour vous en rendre compte, voyez plutôt les quelques captures d’écran disponibles. L’éditeur offre aussi une vue des dépendances sous la forme d’un graphe mais ce plugin relève encore du gadget, devant inutilisable sur des projets un peu conséquents.

M2Eclipse, en compétition avec Q4E pour devenir l’intégration officielle de Maven dans Eclipse (cf The Eclipse Integration for Apache Maven (IAM)), a fait de grands progrès depuis ses premières versions et si vous ne l’avez pas testé depuis longtemps, la dernière version mérite le coup d’œil …

Lors d’un test de performance sur une application J2EE, je note que celle-ci a des soucis de montée en charge. Généralement une ou deux thread dumps peuvent mettre en évidence les points de contentions. Dans mon cas, rien de probant. Je repense alors à l’article publié sur notre blog Chroniques de la performance : À propos de contentions…. Je récupère les sources de l’agent et l’installe sur le serveur d’application, Weblogic 8.1 – JVM 1.4.2. Lancement du tir….

Dès le début de phase plateau, l’agent affiche régulièrement une partie du code que je n’aurais pas soupçonné: la bibliothèque iBatis qui gère l’accès aux données.

[JTPROF] Contention report [id=-1250505672,thread=ExecuteThread: '14' for queue: 'weblogic.kernel.Default',blocked=210ms]
[JTPROF] Stack trace:
[JTPROF]         com.ibatis.sqlmap.engine.accessplan.EnhancedPropertyAccessPlan.<init> (EnhancedPropertyAccessPlan.java:29)
[JTPROF]         com.ibatis.sqlmap.engine.accessplan.AccessPlanFactory.getAccessPlan (AccessPlanFactory.java:62)
[JTPROF]         com.ibatis.sqlmap.engine.exchange.JavaBeanDataExchange.initialize (JavaBeanDataExchange.java:63)
[JTPROF]         com.ibatis.sqlmap.engine.mapping.parameter.BasicParameterMap.setParameterMappingList (BasicParameterMap.java:93)
[JTPROF]         com.ibatis.sqlmap.engine.builder.xml.SqlStatementParser.applyInlineParameterMap (SqlStatementParser.java:431)
[JTPROF]         com.ibatis.sqlmap.engine.builder.xml.SqlStatementParser.processSqlStatement (SqlStatementParser.java:215)
[JTPROF]         com.ibatis.sqlmap.engine.builder.xml.SqlStatementParser.parseGeneralStatement (SqlStatementParser.java:120)

Les temps de blocage affichés vont de 20ms à 500ms !

Analyse

A la lecture de cette pile d’appel, je me dis « encore un bloc synchronisé mal placé dans iBatis« . L’avantage avec l’open source, comme son nom l’indique, est que l’on a accès aux sources. J’ai donc ouvert la classe EnhancedPropertyAccessPlan qui, à ma grande déception, infirma ma 1ère intuition :

27  EnhancedPropertyAccessPlan(Class clazz, String[] propertyNames) {
28    super(clazz, propertyNames);
29    bulkBean = BulkBean.create(clazz, getGetterNames(propertyNames), getSetterNames(propertyNames), getTypes(propertyNames));
30  }

La ligne #29 indique l’appel à une méthode statique de la classe « BulkBean » qui appartient à la bibliothèque cgLib, bien connue pour accélérer efficacement la création de beans Proxy . Idem: cette méthode n’est pas ‘synchronized’. Alors pourquoi l’agent m’indique cette méthode ?
Les grands moyens : injection de traces manuelles dans le code d’iBatis afin de comprendre ce qu’il se trame. Après de nombreux allers-retours de type ‘essais-erreurs’, je finis par trouver l’origine du problème : chaque appel à la méthode BulkBean.create() engendre une levée d’exception NoClassDefFoundError.
En effet, le packaging de l’ear est incomplet : cglib.jar est bien présente mais il manque l’une de ses dépendances : asm. Or le code de la méthode BulkBean.create() s’appuie essentiellement sur l’API d’asm.
Cependant le packaging n’est pas le seul coupable, iBatis est également fautive ! La méthode AccessPlanFactory.getAccessPlan est extrêmement défensive : l’appel à EnhancedPropertyAccessPlan est gardé par un bloc try…catch(Throwable). L’ajout d’un message de log de type « Erreur » aurait été le bienvenue, au moins la première fois.

60:       if (bytecodeEnhancementEnabled) {
61:        try {
62:          plan = new EnhancedPropertyAccessPlan(clazz, propertyNames);
63:        } catch (Throwable t) {
64:          try {
65:            plan = new PropertyAccessPlan(clazz, propertyNames);
66:         } catch (Throwable t2) {
67:            plan = new ComplexAccessPlan(clazz, propertyNames);
68:          }
69:        }

Explications

La levée d’une exception dans une méthode oblige la JVM à rendre l’appel synchronisé afin de garantir un traitement par le catch cohérent. Il ne faudrait pas que les données (attributs, paramètres, variables) aient été modifiées par un autre thread entre la levée de l’exception et son éventuel traitement.

Pour se convaincre de ce phénomène, il suffit d’écrire une simple classe de test : 10 threads, chaque thread appelle une méthode qui suivant un paramètre lève une Exception, une Error ou ne fait rien, et ceci 1 000 000 de fois. Le résultat :

• lorsque la méthode ne lève aucune Exception ou Erreur : Temps de réponse : 89 ms
• lorsque la méthode lève une exception : Temps de réponse 5892 ms, 66 fois plus lent !

Règle: La levée d’exception doit rester un cas exceptionnel et ne dois en aucun cas devenir un design pattern, c’est même un anti-pattern.

public class AntiPattern {
	class NotEvenException extends Exception {
	}
	boolean isEven(int nb) {
		try {
			if (nb % 2 > 0)
				throw new NotEvenException();
			return true;
		} catch (NotEvenException e) {
			return false;
		}
	}
}

Note : Une fois le packaging complet, l’agent jtprof ne mentionne plus du tout cette zone de l’application.

Je vous explique.

Le programme consiste à appliquer massivement un traitement identique à un volume important de données – bref, c’est un batch. Objectif opérationnel : assurer la capacité du système à traiter 50000 dossiers par heure.
L’architecture d’exécution de ce batch est relativement classique : un contrôleur est chargé d’obtenir auprès d’un service métier une liste de dossiers à traiter, de segmenter cette liste en lots, puis de soumettre les lots à un pool de threads qui vont réaliser les traitements en parallèle – chaque lot est traité dans une transaction distincte. Le traitement unitaire d’un dossier est relativement long, de l’ordre de 2 secondes ; les lots sont donc petits – 4 dossiers – pour limiter la durée des transactions.

Au-delà de son rôle de segmentation et de répartition des lots, le contrôleur fournit un ensemble de services de pilotage, qui n’ont pas vraiment de relation avec notre problème, mais que je mentionne pour information : état d’avancement du traitement, interruption, reprise, calcul de statistiques variées, rapports d’erreurs, etc.

Typiquement, avec une telle architecture, le débit total du système est une fonction du temps de traitement unitaire et du nombre de threads simultanés :

Débit Horaire = (3600 / Temps Unitaire) * Nombre de threads

Pour mon batch, le calcul théorique est simple : le traitement de chaque dossier demandant 2 secondes, un thread peut traiter 1800 dossiers par heure. Le débit cible étant de 50000 dossiers par heure il est donc théoriquement nécessaire de démarrer un pool de 30 threads.
Ce calcul cependant part d’une hypothèse audacieuse : il suppose que les temps de traitement unitaire resteront stables quel que soit le nombre de threads. En somme, que la montée en charge du système est parfaitement linéaire.

Or les tests grandeur réelle réalisés en pré-production montrent un comportement assez éloigné de notre équation platonicienne :

Exprimé sous forme de débit, ce même graphe montre une pente inquiétante :

Le débit horaire s’écarte de plus en plus de la valeur théorique idéale et tend vers une valeur désespérément éloignée du débit cible. Pire, il aurait tendance à se dégrader lorsque le nombre de threads devient trop élevé. Pas de panique, cependant, ce comportement ne saurait déstabiliser le briscard de la performance que je suis : de telles courbes révèlent simplement que le système atteint une limite qui interdit la montée en charge. Reste à déterminer quel composant physique ou logiciel en est à l’origine.

La première réaction est naturellement de vérifier qu’aucun composant physique n’arrive à saturation. Les outils ad hoc sont utilisés pour contrôler la consommation CPU, l’overhead du GC, le paging, la bande passante, les I/O disque, etc., je vous épargne le détail. Deux éléments intéressants sont tirés de cette analyse : premièrement, aucun composant physique n’approche ses limites de capacité ; deuxièmement, leur niveau de charge épouse presque parfaitement l’évolution du débit présenté dans la figure 2. En d’autres termes, l’usage des ressources physiques, par exemple la charge moyenne des processeurs, présente la même évolution que le débit : leur montée en charge est freinée et s’écarte inexorablement de la progression théorique linéaire.
Une nouvelle fois, ce sont des caractéristiques relativement communes des systèmes parallélisés : cela signifie que les threads d’exécution entrent en compétition pour obtenir certains verrous, ou pour accéder à certaines sections critiques ; plus le nombre de threads augmente et plus la compétition devient serrée : il faut de plus en plus de temps pour acquérir les verrous.

Dans notre système, deux composants sont susceptibles de créer ces conditions :

• la base de données, qui gère des verrous à différents niveaux
• le code java, au travers de blocs synchronisés

Quiconque a déjà travaillé sur un système transactionnel fortement parallélisé sait que les contentions sur la base de données en sont le principal écueil. Pour assurer l’isolation des transactions, les SGBD posent des verrous en lecture et/ou en écriture sur des lignes, des pages ou des tables – en cas de très forte charge, la granularité des verrous est parfois modifiée dynamiquement, passant par exemple de la ligne (ROW LOCK) à la page (PAGE LOCK).
Notre système batch a été conçu en conséquence : la base est partitionnée selon des axes fonctionnels stricts, les opérations de lecture et d’écriture ont été soigneusement séquencées, les verrous sont posés au niveau des pages et le contrôleur sait exploiter certaines caractéristiques du stockage physique pour calculer et répartir les segments entre les différents threads. Une analyse des contentions sur la base de données a démontré l’efficacité de ces stratégies : le niveau de contention reste remarquablement bas, et n’explique en aucun cas la forte dégradation observée lors de la montée en charge.

Reste une seule explication : des contentions dans les couches d’exécution Java. Et une question : comment identifier l’origine de ces contentions, et les corriger ?

Un premier test est réalisé pour valider l’hypothèse de contentions applicatives dans le code java : il consiste à démarrer 5 processus dotés chacun d’un pool de 4 threads – un total de 20 threads, donc, permettant d’atteindre un taux de parallélisation qui dans nos tests précédents mettaient fortement en exergue la dégradation des temps de traitements unitaires. Ce test est concluant : distribués sur 5 processus distincts, les threads ne sont plus soumis à une compétition mortifère, et la montée en charge se réalise de façon satisfaisante.

Une solution envisageable serait d’adopter cette architecture, et de distribuer les traitements sur plusieurs processus. Le contrôleur, cependant, n’a pas été conçu pour coordonner plusieurs processus. L’évolution la plus simple, consistant à séparer le contrôleur des composants métiers – par exemple au moyen d’EJBs – implique d’introduire une couche de distribution qui nous semble d’autant moins souhaitable que le contrôleur est en charge du pilotage des transactions : le séparer des traitements signifie distribuer les transactions, et tous les petits soucis que cette décision implique généralement. Cela signifie aussi probablement l’introduction d’un serveur d’applications dans l’architecture de batch, avec les difficultés afférentes en terme de déploiement et d’exploitation. D’autres évolutions plus massives sont envisageables : par exemple s’appuyer sur des tables techniques pour stocker les segments, et découpler complètement une phase de pré-processing – consistant à calculer les lots – et une phase de traitement – consistant à piocher des lots dans la base et à les traiter. On peut même imaginer des solutions plus exotiques, à base de files JMS… Mais pour tout dire, nous aimons la compacité de notre architecture initiale, et ne sommes pas prêts à l’abandonner sans résister un peu. La question reste donc entière : comment débusquer l’origine de nos contentions aux fins de les liquider ?

L’analyse statique du code n’a rien donné : le contrôleur, à l’instar des composants métiers, utilise un bon zillion de bibliothèques tierces, plus ou moins open source et au flot d’exécution volontiers cryptique. Impossible dans ces conditions de déterminer l’origine exacte des contentions par simple consultation des sources : une analyse runtime est nécessaire.

Reste à trouver le bon outil dans la sacoche du plombier java. Même avec l’aide gracieuse de Google, la récolte reste maigre en matière d’outillage…

Autant l’offre est pléthorique lorsqu’il s’agit de profiler la consommation CPU ou mémoire des applications Java, autant l’analyse des contentions reste une discipline peu outillée. Certes les profilers java offrent pour la plupart un module d’analyse de threads ; mais leur overhead est tel qu’il est difficile, voire impossible d’instrumenter un traitement fortement multi-threadé comme notre batch : au-delà de 3 ou 4 threads, les informations collectées perdent de leur pertinence, et les temps unitaires s’allongent tellement que toute tentative d’analyse relève de l’acrobatie la plus pure.
Tordons rapidement le cou à hprof, le profiler intégré au JDK – le notre, en l’occurrence, est un JDK IBM 1.4.2 SR8 ; la documentation indique une option « monitor=y », qui, je cite, « tells hprof to generate information on contention monitors used to synchronize the work of multiple threads » (je vous laisse traduire). Bigre, nous voilà sauvés ! Pas tout à fait… Outre que le faire fonctionner a demandé une montée de version du JDK – la version que nous utilisions à l’origine générait un très joli core lors de l’activation de hprof -, les informations obtenues se sont révélées d’une rare inutilité (fondamentalement, un état des moniteurs java au moment de la sortie du processus. Aucun intérêt !).
Exit hprof, donc.
Autre approche : générer de façon répétée des Thread Dump à l’aide de l’instruction kill -3, puis comparer les différents dumps à l’aide d’un outil ad hoc (en l’occurrence un utilitaire disponible sur le site alphaWorks, et dont je donne le nom complet pour souligner le sens du marketing des ingénieurs IBM : IBM Thread and Monitor Dump Analyzer for Java Technology). Bien que prometteuse, cette solution n’a une nouvelle fois pas donné de résultat définitif : elle nous a permis d’identifier quelques méthodes candidates, mais sans qu’il fût possible de quantifier leurs responsabilités respectives.

Reste une solution : retrousser ses manches et écrire un profiler spécialisé en s’appuyant sur JVMPI.
JVMPI (pour Java Virtual Machine Profiling Interface) est, comme son nom le suggère, une API native de profilage de la JVM (remplacée par JVMTI à partir de Java 5, mais c’est une autre histoire). L’API fonctionne sur un système de callback : l’agent (c’est ainsi que l’on nomme le programme s’appuyant sur l’API) s’enregistre auprès de la JVM en précisant les types d’événements dont il souhaite être notifié – vous aurez probablement reconnu le pattern Observer.
Ces événements concernent la plupart des opérations techniques de bas niveau réalisées par la JVM : chargement d’une classe, allocation mémoire, exécution d’une méthode, démarrage d’un thread, etc. Parmi ces événements, deux retiennent particulièrement notre attention : MONITOR_CONTENDED_ENTER et MONITOR_CONTENDED_ENTERED. Le premier indique qu’un thread souhaite exécuter un bloc synchronisé, et tente d’acquérir un moniteur à cette fin (pour mémoire, la notion de moniteur en java est très proche de celle de verrou dans le reste du monde); le second indique que le thread a obtenu le moniteur en question et entame l’exécution du bloc synchronisé. L’intervalle de temps entre les deux événements correspond par conséquent à la durée totale de l’attente – autrement dit à la durée de la contention.
Munis de ces rudiments de JVMPI, il est possible de formuler les spécifications exhaustives de notre petit outil de profilage : la durée de toutes les contentions rencontrées par le programme est mesurée. Si cette durée est supérieure à un certain seuil (disons 5 millisecondes), le nom de la méthode correspondante est loggué dans un fichier, ainsi qu’une pile d’appels simplifiée.

Bien. Il ne reste plus qu’à coder.

Le point d’entrée d’un agent JVMPI est la méthode JVM_OnLoad. C’est dans cette méthode que l’on va informer le sous-système JVMPI des événements que l’on souhaite activer (EnableEvent), et de la méthode callback qui sera invoquée lors des occurrences de ces événements (NotifyEvent) :

JNIEXPORT jint JNICALL _JVM_OnLoad(JavaVM *vm, char *options, void *reserved)
{
    ...
    /* Register callback method */
    jvmpi->NotifyEvent = jtprof_notify_event;
    /* Enable events */
    jvmpi->EnableEvent(JVMPI_EVENT_JVM_SHUT_DOWN, NULL);
    jvmpi->EnableEvent(JVMPI_EVENT_CLASS_LOAD, NULL);
    jvmpi->EnableEvent(JVMPI_EVENT_CLASS_UNLOAD, NULL);
    jvmpi->EnableEvent(JVMPI_EVENT_MONITOR_CONTENDED_ENTER, NULL);
    jvmpi->EnableEvent(JVMPI_EVENT_MONITOR_CONTENDED_ENTERED, NULL);
    jvmpi->EnableEvent(JVMPI_EVENT_THREAD_START, NULL);
    jvmpi->EnableEvent(JVMPI_EVENT_THREAD_END, NULL);
    ...
    return JNI_OK;
}

La méthode callback, jtprof_notify_event, se contente de déterminer la nature de l’événement et de déclencher un handler spécialisé :

static void jtprof_notify_event(JVMPI_Event *event)
{
    switch(event->event_type) {
        case JVMPI_EVENT_JVM_SHUT_DOWN:
            handle_jvm_shut_down_event();
            return;
        ...
        case JVMPI_EVENT_THREAD_START:
            handle_thread_started_event(event);
            return;
        case JVMPI_EVENT_THREAD_END:
            handle_thread_end_event(event);
            return;
        case JVMPI_EVENT_MONITOR_CONTENDED_ENTER:
            handle_monitor_contented_enter(event);
            return;
        case JVMPI_EVENT_MONITOR_CONTENDED_ENTERED:
            handle_monitor_contented_entered(event);
            return;
        ...
    }
}

Les choses semblent relativement simples. L’API JVMPI offre même un système de stockage thread local (méthode GetThreadLocalStorage), permettant de conserver une structure de données quelconque dédiée à chaque thread. Je vous épargne les détails de la création et de la destruction de cette structure de données – les curieux pourront jeter un oeil sur le code source. Sachez simplement qu’elle est créée lors de l’événement THREAD_START, détruite lors de l’événement THREAD_END, et qu’elle permet notamment de conserver la date de la demande d’acquisition du moniteur par le thread.

Au final, le code permettant de mesurer la durée d’acquisition d’un moniteur est relativement trivial :

static void handle_monitor_contented_enter(JVMPI_Event *event){
    thread_local_context *ctx = (thread_local_context*)jvmpi->GetThreadLocalStorage(event->env_id);
    //Error handling code
    ....
    ctx->timer = system_current_time_millis();
}
static void handle_monitor_contented_entered(JVMPI_Event *event){
    long finish = system_current_time_millis();
    long total;
    thread_local_context *ctx = (thread_local_context*)jvmpi->GetThreadLocalStorage(event->env_id);
    //Error handling code
    ....
    total = finish – ctx->timer;
    ctx->timer = 0;
    if (total > __contention_threshold){
        //Log contention details
        ....
    }
}

Les choses, bien sûr, sont en réalité un poil plus complexes – fallait pas rêver, non plus.
Par souci d’efficacité, en effet, la structure de données JVMPI_Event ne contient, pour chaque événement, qu’un jeu minimal d’informations. En pratique, cela signifie que le nom de la méthode invoquée n’est pas disponible sous forme littérale, mais sous la forme d’un identifiant interne créé lors du chargement de la classe correspondante.
Logguer cet identifiant ne serait bien sûr pas d’un grand intérêt. Il faut pouvoir l’associer au nom qualifié de la méthode. Pour cela, l’événement CLASS_LOAD doit être traité. Cet événement fournit la définition complète de la classe et de toutes ses méthodes – y compris leur nom littéral. Notre programme conserve donc ces informations dans un tableau associatif (dont le code source est très largement inspiré de celui de hprof). Ce tableau peut ensuite être consulté lors du traitement d’une contention afin de déterminer le nom de la méthode appelante à partir de son identifiant. Une technique similaire est mise en oeuvre pour expliciter la pile d’appels. Je vous laisse consulter le code source pour les détails…

Le programme doit être compilé sous forme de bibliothèque dynamique (extension .dll sous Windows, .so sous Unix), inclu dans le LIB_PATH (ou son équivalent) et intégré à la JVM grâce à l’option -Xrunjtprof (jtprof est le nom donné à la bibliothèque). Voici le type de sorties obtenues :

[JTPROF] Contention report [id=-2002923824,thread=Contention-Thread-4,blocked=305ms]
[JTPROF] Stack trace:
[JTPROF]	 org.test.Contentions.blockABitMore (Contentions.java:36)
[JTPROF]	 org.test.Contentions.run (Contentions.java:25)
[JTPROF]	 java.lang.Thread.run (Thread.java:595)
...
[JTPROF] Thread end [id=-2002912512, name=Contention-Thread-6, duration=1519ms, blocked=1416ms]

Une fois mis au point, cet outil s’est révélé très précieux. Son overhead est très faible – les événements les plus gourmands, comme les sites d’allocation mémoire ou la consommation CPU des méthodes, ne sont pas traités. Il nous a fourni un état très précis du niveau de contention, et de la localisation de celles-ci. Une douzaine de méthodes ont été corrigées (la plupart des contentions étaient de très courte durée – rarement plus de 50ms – mais leur fréquence et leur durée avaient tendance à augmenter).
Au terme de ces optimisations, la courbe des débits se présente comme suit :

Il reste un léger décrochage au-delà de 25 threads, mais cette fois-ci, son origine ne fait pas de doute : notre machine de test est simplement saturée, et la contention, cette fois-ci, porte sur l’accès aux processeurs.

Ceux qui ont suivi depuis le début se souviennent peut-être de l’équation présentée plus haut dans cet article :

Débit Horaire = (3600 / Temps Unitaire) * Nombre de threads

S’ils n’ont pas complètement oublié le programme de mathématiques du Brevet des Collèges, ils auront probablement compris que l’augmentation du nombre de threads n’est pas le seul levier du débit : réduire le temps de traitement unitaire en est un autre. Mais ceci est une autre histoire…

Cette vidéo traite des numéros :

• 04 : Les bibliothèques tierces
• 03 : Mauvais usage de la concurrence

Cette vidéo traite des numéros :

• 06 : Utilisation impropre des caches
• 05 : Utilisation excessive de la mémoire

Cette vidéo traite des numéros :

• 08 : Usage incorrect de Java EE
• 07 : Utilisation abusive du XML

Cette vidéo traite des numéros :

• 10 : Logging excessif
• 09 : Mauvaise configuration du serveur d’application

• #10 – Logging excessif
• #09 – Mauvaise configuration du serveur d’application
• #08 – Usage incorrecte de Java EE
• #07 – Utilisation abusive du XML
• #06 – Mauvaise utilisation des fonctions de ‘Cache’
• #05 – Consommation mémoire
• #04 – Mauvaises performances des bibliothèques tierces
• #03 – Mauvaise gestion de la concurrence
• #02 – Utilisation abusive de la distribution
• #01 – Mauvaise utilisation de la base de données

De ce classement, Vincent Partington tire les conclusions suivantes:

• Tout d’abord, les architectes et développeurs Java devraient considérer la performance comme une exigence de leur application, à toutes les étapes du projet.
• Ensuite, les équipes de développement ont besoin de collaborer avec des personnes qui peuvent les aider à améliorer les performances de leurs applications, en particulier les administrateurs de serveurs d’applications et les DBA.
• Enfin, la performance requiert des connaissances dans un grand nombre de domaines, dont ce Top Ten met en avant les plus critiques. Pour un tour d’horizon plus complet, un bon point de départ est le site web the Java Performance Tuning

J’ai assisté, il y a peu, à une excellente présentation de l’AOP et de AspectJ plus particulièrement. J’ai tout de suite été séduit et j’ai donc cherché des applications pratiques pour ce genre de technologie.
Le cas d’école pour apprendre l’AOP que l’on trouve régulièrement est l’exemple du logging.

public aspect LoggerAspect {
	pointcut log() : call(* *.methodToLog(..));
	before() : log() {
		System.out.println("Avant l'exécution de"+thisJoinPoint.toShortString()) ;
	}
	after() : log() {
		System.out.println("Après l'exécution de"+thisJoinPoint.toShortString()) ;
	}
}

Cet aspect affiche un message avant et après l’appel de la méthode.

Je vous propose ici de modifier cet exemple pour effectuer des mesures de performance dans une application.
Pour cela nous pouvons utiliser JAMon qui permet de positionner simplement des prises de mesure et de les consulter au travers d’une application web fournie. Dans JAMon, on utilise des Monitor auquel on associe un nom logique.

Pour notre prise de mesure, nous voulons savoir combien de temps on passe dans telle ou telle partie de code. A la différence de l’exemple du login, le pointcut que nous allons définir va utiliser le mot-clé execution plutot que call pour se positionner au plus près du code exécuté.

La définition du _poincut_ sera d’autant plus simple si le code que l’on doit monitorer a été contraint par des règles de nommage ou si les éléments du code utilise ou hérite d’un framework.

Exemple :

pointcut monitor() : execution(* *.*Service.*(..)) ; // Correspond à toutes les méthodes des classes qui finissent par <em>Service</em>
pointcut monitor() : execution(* *.GenericService+.*(..)) ; // Correspond à toutes les méthodes des classes qui héritent de la classe <em>GenericService</em>
pointcut monitor() : execution(* *.services.*.add*(..)) ; // Correspond à toutes les méthodes qui commencent par <em>add</em> des classes qui sont dans le package *.services.*

Ensuite, Il faut définir l’advice. Nous voulons savoir combien de temps prend l’exécution des méthodes correspondant au pointcut. Nous utiliserons donc le mot-clé arround() qui permet d’effectuer des pré\- et post-traitements.

Puisque nous allons positionner ces prises de mesure avec de l’AOP, nous utiliserons thisJointPoint.toShortString() (qui donne le nom court du pointcut) comme nom pour le Monitor JAMon que nous positionnerons.

Voici l’exemple complet :

public aspect PerfMonitor {
	pointcut monitor() : execution(* *.ClassToMonitor.methodToMonitor(..)) ;
	Object arround() : monitor() {
		Monitor monitor = MonitorFactory.start(thisJoinPoint.toShortString());
		Object returnedObject = proceed();
		monitor.stop();
		// Si on veut avoir une trace de la mesure dans les logs
		// LogFactory.getLog(getClass()).debug(monitor.toString()) ;
		return returnedObject;
	}
}

Une fois, notre aspect définit, nous allons pouvoir voir ce que donne notre prise de mesure.

La distribution de JAMon contient une application web qui permet de visualiser les statistiques des différents Monitor positionnés dans le code.

Pour que cela fonctionne simplement, il suffit de déposer le fichier jamon.jar dans le répertoire de librairie partagée (ex: common/lib sous Tomcat) afin que les classes de JAMon soient chargées par le « system class loader ». Ensuite, déployer l’application web jamon.war comme n’importe quelle application.

Une fois votre application démarrée, vous pouvez accéder à la page http://webserver/jamon/jamonadmin.jsp pour voir les statistiques produites par le monitoring de votre code.

Voici un exemple du rendu de cette page :

Remarque : JAMon fournit d’autres possibilités de prise de mesure :

• le ServletFilter JAMon qui va mesurer le temps de chargement de chaque page pour avoir un aperçu global des performances de l’application.
• le JAMonDriver ou la JAMonDataSource qui encapsule le vrai driver JDBC pour mesurer les accès à la base de données.

Ce genre d’outil est surtout en mode « diagnostic » pour trouver et optimiser les traitements coûteux plutôt que pour effectuer de véritables tests de performance sur une application.
L’avantage de le combiner avec de l’AOP, c’est de permettre de « monitorer » des traitements dont nous n’avons pas le code source.

L’outil Glassbox qui permet de faire des prises mesures automatiquement dans une application se base justement sur l’AOP pour positionner ses messures.