• Comment troubleshooter des problèmes de performances : les points d’entrées de l’investigation,
• Nouveaux langages sur la JVM : Scala, Clojure, …
• Cloud computing et virtualisation,
• JVM et appliances Java : Hotspot, jRockit, IBM J9, Azul, ExaLogic, …
• Support des large heaps : G1, Direct Memory, …
• … et quelques recommandations de programmation en Java.

Bonne écoute !

Après une intervention controversée de Matt Raible à Devoxx 2010 concernant la comparaison de frameworks Web, cette année trois personnes ont choisi de remettre le couvert :  Stijn Van den Enden, Guy Veraghert et Ward Vijfeijken.

Stijn débute la présentation en nous rassurant : leur recherche concerne une poignée de frameworks Web et est basée sur la scalabilité. Pour lui cette dernière est une notion importante :

• Elle influe sur l’infrastructure
• Elle assure une qualité de service
• Elle a un coût non négligeable

Stijn nous explique qu’ils ont pris le parti de baser leur expérience sur les frameworks Web suivants :

• GWT
• JSF
• Wicket
• Spring MVC

Il poursuit avec le type d’application qui les intéresse :

• Ecrans détaillés
• Navigation de pages
• Autocompletion
• Ajax validation
• Mise à jour du DOM

Ensuite pour tester la scalabilité de ces frameworks, l’expérience a porté sur :

• Les temps de réponse
• Think time (temps d’attente par un utilisateur avant de pouvoir effectuer une autre action)
• Throughput (nombre de requêtes en succès par secondes)

Concernant la plateforme, les tests ont été effectués sur Amazon Web Server avec un Tomcat et une base de donnée MySQL.

Avant de nous dévoiler les résultats, Stijn nous explique que pour les analyser son équipe s’est basée sur le modèle théorique de la loi de Little afin d’avoir une référence pour faire parler les données. En résumé, le principe est de trouver un optimum concernant les temps de réponse et le nombre de threads supportés.

Ayant collecté énormément de données (plus de 300 millions de mesures), l’équipe a mis en place une application Web permettant de tracer des graphiques basés sur un bon nombre de paramètres activables / désactivables (CPU data, Memory data, nombre d’utilisateurs, etc..)

Après toutes ces explications sur l’environnement de tests, les résultats tombent enfin :

GWT est le grand gagnant suivi de très près par Spring MVC. Un peu plus loin nous avons Vaadin et dans les plus mauvais élèves nous retrouvons dans l’ordre JSF/Wicket et MyFaces. L’équipe a choisi d’intégrer Vaadin et MyFaces car ils n’avaient pas beaucoup de modifications à apporter.

A ce stade de la présentation, l’équipe nous dévoile qu’elle a été plus loin : la réalisation de tests sur le rendu des navigateurs.

Leur principal problème était que JMeter ne permet pas ce genre de tests. Ward nous présente alors leur solution: des plugins sur les navigateurs (firebug + network, Chrome developpment tool, HTTPWatcher) permettent d’extraire les données. Il nous parle ensuite de l’outil HAR Viewer qui permet d’interpréter et analyser ces données exportées, et nous explique l’automatisation de ces processus avec Selenium Web Server.

Encore une fois les résultats tombent : Wicket est le gagnant suivi de JSF, GWT et Spring MVC.

Néanmoins, Ward nous explique que les résultats sont légèrement biaisés : HAR déclenche son analyse trop tôt pour GWT. En effet, ce dernier a besoin de télécharger les javascripts avant de pouvoir effectuer un rendu. Des solutions en cours de développement peuvent y remédier (W3C Navigation timing API et W3C Resource timing API), mais ne sont pas encore disponibles.

Ward finit par nous présenter rapidement l’outil SpeedTracer, capable d’analyser les points de contentions sur les navigateurs (disponible seulement sous Chrome).

A travers tous ces tests, nous voyons que l’équipe a réalisé un travail réfléchi : mise en place d’un bon environnement de test, modèle théorique d’analyse des données, etc…, rendant les résultats justifiés et pertinents. Nous pouvons cependant regretter qu’ils n’aient pas intégré d’autres frameworks Web.

L’équipe conclue par le palmarès des frameworks en terme de coût de scaling pour 10000 utilisateurs avec des temps de réponse moyen à 200 ms

Le résultat final est GWT en premier, Spring MVC et JSF/Wicket.

Pour finir, Stijn ouvre le débat et pose la question suivant : c’est bien d’être rapide, mais le framework Web est-il vraiment le point de contention ? A méditer.

• Une solution pour le marshalling JSON
• Un serveur web NIO supportant le long polling
• Une solution pour la persistence et le partage des données

Notre démarche a été de réaliser des POCs implémentant la création des utilisateurs et le long polling pour retenir la meilleure solution. La solution devait être simple et rapide à implémenter, et tenir une charge conséquente en la testant à l’aide de ab l’outil de benchmark Apache et de la librairie Async Http Client. Pour le JSON, nous nous sommes tous rapidement mis d’accord sur l’utilisation de la librairie Jackson. Nous étions tous convaincus qu’il nous faudrait un serveur web NIO sans passer par la case Servlet. C’est à partir de là que notre tour d’horizon des API NIO en Java a commencé.

Pourquoi NIO ?

Revenons d’abord à l’essentiel, nous ne pouvons justifier notre choix sans expliquer ce qu’est cette API Java. Cette API existe depuis la version 1.4 du JDK et permet essentiellement de réaliser des traitements non-bloquants sur les entrées-sorties. NIO est en fait l’acronyme de New IO, la nouvelle api java.nio vient en supplément de l’API java.io existante.
Prenons l’exemple d’une Socket en Java, par défaut les opérations de lecture et d’écriture sont bloquante. Le thread lançant une opération de lecture ou d’écriture sur Socket sera bloqué sur cet appel tant que l’opération ne sera pas terminée. Tant qu’il n’y aura rien à lire sur la socket ou qu’il n’y aura pas d’espace disponible pour écrire dessus, le thread sera bloqué. Il sera aussi débloqué en cas d’exception dû à un timeout par exemple.

Depuis java.nio, il est possible de réaliser ces appels sans avoir à attendre qu’il y ait de l’espace libre ou des données à lire sur la Socket. Pour éviter ce temps de bloquage, l’API fournit un système pour écouter les évènements sur les sockets il s’agit du Selector. On enregistre la ou les Sockets dans le selector en précisant si l’on veut lire et/ou écrire, et/ou accepter des connexions sur la socket. Sur chaque appel à select(), le sélecteur créera une liste des Channel pour lesquels une opération est prête à réaliser. Bien sûr, le serveur devra toujours attendre qu’il y ait des opérations disponibles sur ses sockets clients, mais la grande différence est que le serveur attend une fois pour l’ensemble de ses clients au lieu d’attendre une fois par client.

Pendant que le thread de l’API historique java.io attend un client, un Thread utilisant java.nio pourra traiter d’autres clients. Pour traiter les requêtes en parallèle avec l’API java.io, il suffit de multiplier le nombre de Thread avec un thread par client, il n’y aura pas d’attente non plus. Malheureusement on ne peut pas multiplier indéfiniment les Threads sans impact sur l’espace mémoire. Dans le cadre du challenge, nous étions limités en mémoire et nous devions supporter le maximum possible de client concurrents. Avec son faible nombre de Threads (1 par CPU) et donc sa consommation de mémoire inférieur, NIO est rapidement devenu une évidence pour tous.
Pour ces même raisons, nous avions décidé d’éliminer les serveurs de Servlet. L’API Servlet est consommatrice par essence et apporte une quantité non négligeable de raffinements dont nous n’avions pas besoin. Depuis l’API Servlet 3.0, il est possible de réaliser des Servlets Asynchrone qui permettent de libérer le Thread d’exécution de la requête pour envoyer la réponse plus tard à partir d’un autre Thread. Par curiosité nous avons donc testés Tomcat 7 en Servlet asynchrone, avec de forts à priori.

Le test

Afin de départager les différentes API, nous avons réalisé une implémentation du service de création des utilisateurs qui les persistent dans une Map. Quelque soit le framework, le service de mapping du JSON et de persistance sont les mêmes. Ainsi, nous pouvions nous intéresser à notre seul problème: la performance du serveur HTTP. Les tests ont été réalisés sur un macbook pro 2,4 Ghz core i5 sans optimisation de JVM. Les seules modifications réalisées sur le système sont:

• L’augmentation du nombre de port éphémères via sysctl net.inet.ip.portrange.first
• La réduction du maximum segment lifetime afin de réduire la durée de réservation des sockets en TIME_WAIT.
  Ces configurations ont pour seule but de permettre à ab d’injecter une charge conséquente sans souffrir de timeout dûe à un nombre trop élevé de socket réservé.

Tour d’horizon des implémentations NIO

Restlet

Restlet est un framework REST qui embarque le serveur HTTP et permet de choisir parmi différentes implémentations de Mina par défaut à Jetty en passant par Grizzly et Netty.
Restlet, semblait donc parfaitement adapté à la réalisation du serveur REST tout en nous offrant la possibilité de choisir le serveur à utiliser. En ultime recours sachez tout de même qu’il est parfaitement possible d’embarquer Restlet dans un war.
Nous avons donc créé un POC pour le service de création des utilisateurs (1Million d’utilisateurs en moins d’une heure). Après quelques tests rapides, l’API est convaincante pour sa simplicité d’utilisation et sa rapidité de prise en main. Mais les performances ne sont pas à la hauteur de nos espérances. Nous étions bien sûr largement capables de créer le million d’utilisateur en moins d’une heure, mais le temps passé dans les API Restlet, Mina et Jetty était trop impactant. Nous avons testé ce POC avec Mina et Jetty sans nous intéresser aux autres solutions que nous souhaitions tester en direct. Pour la solution Jetty, ab indiquait en moyenne 5k requêtes par secondes pour un temps de traitement moyen de 11ms à la création des utilisateurs. Si cette performance est encourageante et s’avère la meilleure disponible toute implémentation de serveur confondue, il y a tout de même une consommation en mémoire importante et des points de synchronisation bloquants. Pour le test via Mina la solution par défaut, les tests de charge supportaient mal l’augmentation du nombre d’injecteurs qui cause une cascade de Timeout. D’autre part alors que Jetty se limite à 80 Threads, avec son implémentation Mina, Restlet crée rapidement des centaines de Threads et consomme beaucoup de mémoire. Retenez donc que l’implémentation Jetty NIO de Restlet est très performante et répondra à la majorité des besoins en informatique de gestion.

Tomcat 7

Le développement de ces POCs était une bonne occasion pour tester Tomcat 7 et les Servlets 3.0. Nous avons donc implémenté notre service avec des Servlets déclarées par annotation et utilisant l’exécution asynchrone pour maximiser le nombre de connexions concurrentes supportées.
Notez que l’utilisation des Servlets asynchrones a un impact immédiat sur les performances du serveur. La version asynchrone de la solution supportait effectivement plus de connexions avec des temps de réponse à peu près similaires. Le simple fait de passer la Servlet en traitement asynchrone permet donc de gagner en performance. Malheureusement en examinant les ThreadDump, il était clair que Tomcat avait un gros impact sur les temps de réponse (files d’attente et autre point de synchro était omni-présent).
Une dernière remarque, les tests ont été réalisés en utilisant deux connecteurs HTTP différents : le standard et le NIO. La solution NIO était bien plus performante en terme de parallélisme, mais le connecteur souffrait alors d’une fuite de mémoire conséquente. Le connecteur NIO de Tomcat aurait pu être une bonne option, mais nous ne voulions pas partir sur une solution reposant d’emblée sur des API instables comme c’était le cas du connecteur. A priori le bug a été corrigé dans les versions suivantes de Tomcat. Notez aussi que Tomcat a une empreinte mémoire importante et implique l’utilisation quasi permanente du GC car la mémoire utilisée dans la heap augmente régulièrement.

Grizzly

Pour mémoire, Grizzly est l’API réseaux utilisée par GlassFish. La librairie fournie un serveur de Servlet et un framework de traitement réseau NIO, “haute performance”. Tant qu’à faire, c’est à la partie framework NIO que nous nous sommes intéressés. Pour créer le serveur, il suffit d’utiliser HttpServer.createSimpleServer() auquel on ajoute ensuite des HttpRequestProcessor mappés par URL. Bien que très mal documentée, l’API est simple à mettre en place. Le problème vient plutôt du fine tuning car il est facile de changer le port d’écoute et d’activer le monitoring JMX, par contre la gestion des ThreadsPool s’avère bien plus complexe. Il n’existe pas dans Grizzly un moyen simple de spécifier son ExecutorService. Sur le scénario simple d’injection des utilisateurs, Grizzly crée rapidement plusieurs centaines de Threads et souffre de nombreux points de synchronisation. N’ayant pas beaucoup de temps à consommer dans cette phase de POC, nous avons rapidement éliminés Grizzly qui nécessitait d’emblé des optimisations et ne répondait pas aux besoins directement sorti de sa boite. En tests nous avons atteint une moyenne de 1500 req/s pour l’injection de 100k joueur dans une simple HashMap. Notez tout de même que Grizzly supporte différentes stratégies pour gérer les IO (http://grizzly.java.net/nonav/docs/docbkx2.0/html/iostrategies.html), par défaut il applique le WorkerThread qui consiste à déléguer le traitement des IO à un worker séparé. Nous n’avons pas testé d’autres stratégies que celle par défaut; cela aurait nécessité plus de temps que nous ne souhaitions en allouer au POC. En résumé, les tests sur grizzly se sont avérés décevants; avec plus de temps nous aurions sûrement amélioré ces performances.

Deft

Deft est une implémentation Java s’inspirant de Tornado, le serveur HTTP de facebook en python. Son principe est de créer une boucle infinie unique exécutant l’ensemble des évènements remontés par le Selector dans le même thread. Comme dans NodeJS, ce système permet de réaliser les traitements de façon évènementiel sans se soucier de la concurrence. Avec quelques tests sur un seul Thread, nous avons constaté des performances impressionnantes. En temps de réponse, en nombre de requêtes concurrentes, comme en consommation mémoire le serveur dépasse l’ensemble de ses concurrents sans aucune optimisation. Il y avait toutefois quelques bugs rédhibitoires dans l’API causant des erreurs graves à l’exécution de certains tests de charge. Le code étant simple, Séven a réalisé des corrections de bugs et implémenté un mode multi-thread permettant de lancer plusieurs boucles infinies pour tirer au mieux parti des CPU multi-coeurs. Sur le test d’injection de 100k joueurs, nous avons atteint entre 10 et 11k req/s pour une moyenne de 6ms de temps de réponse. Pour Deft, nous avons donc fait exception à la règle du temps consommé, n’étant jamais à l’abri d’une bonne surprise cela pouvait valoir le coups. Au final, l’API étant encore un peu trop instable et manquant de raffinement, comme la gestion des cookies ou le support de la compression gzip, ou encore une solution clé en main de longpolling, nous avons abandonné ce POC pourtant prometteur. Notez que, depuis la fin du challenge, le projet est rentré en incubation chez Apache avec pour but de fournir un serveur Java haute performance non J2EE. L’histoire continue pour Séven qui a rejoint l’équipe des commiters de ce nouveau projet Apache.

Netty

Netty est le framework NIO de JBoss, il permet de créer rapidement un serveur HTTP. Netty utilise deux ThreadPool, l’un pour écouter et accepter les connexions entrantes et l’autre pour traiter les échanges de données sur socket établies (Boss / Worker). Il définit ensuite une liste de Handler permettant de traiter les messages lus et d’écrire une réponse. Les handlers se comportent comme des filtres passant un événement portant un message, ils sont invoqués dans le sens de la lecture puis dans le sens de l’écriture vers le SocketChannel. La création d’un serveur HTTP nécessite donc de configurer les décodeurs dans le bon ordre mais l’exemple fournit dans la documentation permet de mettre le tout en œuvre en quelques minutes. Pour les habitués des documentations Jboss, notez que celle de Netty est riche et lisible : un bel effort pour ces experts du labyrinthe. Netty a l’avantage de supporter nativement le long-polling et de parfaitement gérer les envois de réponse en masse sur les sockets client. Sur le test d’injection des 100k utilisateurs, nous avons atteint les 9k req/s pour des temps de réponses de 6ms en moyenne. Pendant le test, Netty alloue un peu de mémoire supplémentaire mais se stabilise rapidement sans avoir d’activité GC. Comme vous pouvez le constater, cette solution supporte une charge légèrement inférieure mais apporte une stabilité accrue par rapport à Deft et surtout bénéficie d’optimisation pour le long-polling. La seule optimisation dont nous avons eu besoin par rapport au code de démonstration, fût l’utilisation d’un MemoryAwareThreadPool en lieu et place du CachedThreadPool qui causait un goulet d’étranglement. C’est donc la maturité de l’API, la simplicité d’usage et la performance de la solution qui ont fait la différence au final sur notre choix.

Conclusion

Pour conclure, ce tour d’horizon nous a permis finalement de découvrir qu’avec un peu d’optimisation, il est facile de faire des serveurs de hautes performance en reposant sur nos bons vieux serveurs J2EE comme Tomcat et Jetty. Les solutions NIO font surtout la différence sur l’application du long-polling, et les réponses groupées. Ainsi que sur la consommation mémoire et le nombre de Thread utilisés favorisant ainsi l’économie des FullGC et plus globalement du temps de traitement du garbage collector. NIO prend tout son sens pour le messaging et les serveurs de type événementiels. Parmi les API NIO non couvertes par nos tests, notez aussi l’existence de Simple : un serveur web prometteur permettant d’héberger des application Jersey en JAX-RS et intégré dans Restlet.
Vous trouverez les sources des pocs sur le GitHub de Xebia: https://github.com/xebia-france/NIO

Pour cet atelier, nous vous fournirons une application Spring MVC consommant les WebServices d’une seconde application web à déployer sur vos machines. Vous aurez à votre disposition les scripts JMeter pour générer de la charge sur vos déploiements. Vous serez en compétition avec notre expert performance qui en parallèle vous exposera sa méthode et ses résultats. À chaque optimisation trouvée, Kirk pourra expliquer plus avant le problème et comment l’identifier, puis détaillera sa solution.

Nous terminerons l’atelier par une séance de questions/réponses avec Kirk. Puis, un buffet campagnard sera proposé, offrant à chacun le temps d’échanger sur le sujet et de diner bien sûr.

Cet atelier gratuit aura lieu le mercredi 7 Décembre à 19h00, l’inscription sera ouverte très prochainement sur EventBrite (le lundi 14 novembre à 9 heures).

Merci encore et à bientôt !

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 .

Le framework The Grinder

C’est quoi The Grinder ?

The Grinder est un framework de test de charge « Jython-based scripting » écrit en Java. Il est open source (sous licence BSD) et  hébergé chez sourceForge.

Il permet de tester:

• Les serveurs web en mode HTTP /HTTPS.
• Tout ce qui vit dans un serveur d’application (Web service SOAP/REST, EJB, JMS,…)
• Les bases de données avec JDBC.
• Les servers FTP, POP3, SMTP, LDAP.

The Grinder s’exécute sur une plateforme supportant une version Java 1.4 ou supérieur.

Il peut être utilisé à des fins telles que :

• Test fonctionnel : contrôler le rendu de l’application par rapport au résultat attendu.
• Test de charge : vérifier que l’application peut supporter une charge donnée.
• Test de capacité : connaître la charge maximale supportée par l’application avant l’apparition d’erreurs
• Test de stress : vérifier la stabilité de l’application.

Historique

The Grinder, « Le moulin », a été initialement développé pour les besoins du livre J2EE Performance Testing with BEA WebLogic Server par Paco Gómez et Peter Zadrozny.

Par la suite, Philip Aston a pris possession du code et l’a retravaillé pour en créer The Grinder 2.

C’est en Juillet 2003 que la première édition du livre fut publiée par Peter, Philippe et Ted Osborne, faisant ainsi un usage intensif de l’outil à sa deuxième version (The Grinder 2).

Peu après, Philip Aston commence à travailler sur The Grinder 3. Cette version offre de nombreuses nouvelles fonctionnalités, la plus importante est le Scripting Jython.

Environnement de développement

• Eclipse 3.6.
• Apatana 3/Pydev : plugin eclipse pour le développement de projets python :
  • Update Site : http://download.aptana.com/studio3/plugin/install
• Grinder Stone : plugin eclipse pour exécuter les scripts grinder. Il permet également de lancer des sessions de debugging.
  • Update Site : http://grinderstone.googlecode.com/svn/update/site.xml
• Jython 2.2.1
• Grinder 3.4

Architecture & Conception des Scripts

Architecture

Il est important de comprendre l’architecture du framework,  ses différents composants et son mode fonctionnement.

Afin d’illustrer ce propos, je vous propose les deux schémas ci-dessous ;  l’un qui fait apparaitre les composants de base d’une plateforme d’injection d’un point de vue conceptuel, et l’autre illustrant l’architecture et les terminologies spécifiques à The Grinder.

Design View

The Grinder View

• La console contrôle les workers (les injecteurs) par le biais des agents et se charge d’agréger les résultats de test de l’ensemble des injecteurs de tous les agents.
• Les agents sont en charge de piloter un ou plusieurs worker (généralement une instance « agent » est créé par JVM).
• Les workers (grinder.processes) permettent d’injecter la charge au système à tester en démarrant le nombre de thread spécifié par la clé « grinder.threads » (les utilisateurs virtuels) et remontent les statistiques à la console. Chaque thread ainsi créé, exécute le script de test « grinder.runs » fois.

Conception des scripts et des scénarios

Le diagramme ci-dessous permet d’illustrer la séquence d’exécution d’un script grinder (gérée par le framework) couplée avec celle d’un scénario composé de deux tâches (gérée par le développeur) :

Généralement les scénarios fonctionnels à dérouler se différencient  en bout de chaîne, ou plus simplement dit, partagent un certain  nombre de transactions (Tâches) ; Ce qui fait apparaître le besoin de décomposer vos scénarios en un ensemble de tâches réutilisables.

Le lien entre deux tâches successives (récupérer l’output d’une tâche pour le faire passer en input de la tâche suivante) est réalisé par la requête suivante:

HTTPPluginControl.getHTTPUtilities().getLastResponse()

Un scénario est donc défini par la succession d’un ensemble de tâches. Il encapsule la logique d’exécution de ses tâches (Scenario.run()).

Un « ScenarioAScript » permet la création et l’initialisation d’un « Scenario » composé de deux tâches « Task1 » et « Task2 ». Il est également responsable de la gestion de la rampe pour son scénario se traduisant généralement par une attente d’une durée égale au « pacingTime » (le temps d’attente entre le lancement de la première exécution de deux Threads successifs).

Un « Tir » constitue le script d’entrée pour The Grinder, il joue le rôle d’un orchestrateur et permet de répartir les threads sur l’ensemble des scénarios (affectation Thread / ScenarioXScript) selon la configuration souhaitée.

L’exemple ci-dessous permet de répartir les threads sur 3 scénarios avec les proportions suivantes : le  ScenarioAScript 50%, le ScenarioBScript 25 % et le ScenarioCScript 25 %

from net.grinder.script.Grinder import grinder
scripts = ["ScenarioAScript", "ScenarioBScript", "ScenarioCScript"]
# Ensure modules are initialised in the process thread.
for script in scripts: exec("import %s" % script)
def createTestRunner(script):
    exec("x = %s.TestRunner()" % script)
    return x
class TestRunner:
    def __init__(self):
        tid = grinder.threadNumber
        if tid % 4 == 2:
            self.testRunner = createTestRunner(scripts[1])
        elif tid % 4 == 3:
            self.testRunner = createTestRunner(scripts[2])
        else:
            self.testRunner = createTestRunner(scripts[0])
    # This method is called for every run.
    def __call__(self):
        self.testRunner()

Ce qu’il faut savoir

Réinitialisation des cookies au lancement de chaque run

Il faut savoir qu’à chaque run, The Grinder effectue un « cookie-reset » ; ce qui pourrait être très embêtant dans le cas où votre démarche de test s’inscrit dans la logique suivante:

• S’authentifier (création de la session, initialisation des cookies)
• Boucler sur le scénario fonctionnel n fois
• Se déconnecter

Pour pallier ce problème, la solution la plus simple consiste à récupérer l’ensemble des cookies initialisés au démarrage de la session lors du premier run et les injecter par la suite dans les runs qui suivent comme suit :

# récupérer l’objet HTTPClientContext pour le thread en cours au premier run.
threadContext = HTTPPluginControl.getThreadHTTPClientContext()
#récupération de l’ensemble des cookies au premier run
cookies=CookieModule.listAllCookies(threadContext)
      # récupérer l’objet HTTPClientContext pour le thread en cours.
      threadContext = HTTPPluginControl.getThreadHTTPClientContext()
      # Injection des cookies dans le header http du thread en cours
      for cookie in cookies:
          CookieModule.addCookie(cookie, threadContext)

Une deuxième solution est envisageable ; Il s’agit de désactiver la gestion automatique des cookies :

HTTPPluginControl.getConnectionDefaults().useCookies = 0

et de créer son propre « handler » de cookie :

# un « implements » à la python de l’interface «CookiePolicyHandler»
class MyCookiePolicyHandler(CookiePolicyHandler):
    # implement your own cookie acceptance policy.
    def acceptCookie(self, cookie, request, response):
        # traitement souhaité
        return 1
    # control the sending of cookies according to the matching rules
    # for the path, domain, protocol, etc
    def sendCookie(self, cookie, request):
        # traitement souhaité
        return 1

Par la suite, quelque part dans vos scripts, vous devrez faire un « set » du custom-handler :

CookieModule.setCookiePolicyHandler(MyCookiePolicyHandler())

Http/GET non implicite des ressources statiques

Les requêtes http exécutées par le framework ne permettent pas de récupérer systématiquement les ressources statiques (cacheables par défaut) liées à la page demandée, comme les fichiers de type *.css, *.jpeg, *.gif, *.jar,… Il faut donc penser à les récupérer explicitement (par un http/GET du fichier en question) dans le cas où vous jugerez que cela pourrait avoir un impact sur les résultats de test.

Gestion des « runs »

A un certain moment, lors du développent de vos scripts,  vous auriez été tentés de gérer le nombre d’exécutions (grinder.runs) par vous-mêmes afin de contourner certains problèmes, notamment celui du cookie-reset précédemment évoqué. Je comprendrais que vous eussiez été plus à l’aise avec un « loop » et des « if » pour implémenter toute la logique d’exécution souhaitée, mais vous auriez sans doute constaté que les temps de réponse augmentaient d’une manière aberrante et proportionnelle au nombre de VUs (grinder.threads) ; ce qui est certainement lié à la contention des ressources et des threads dans vos « loop ». Je voulais donc en venir à la règle suivante: « Déléguer au framework ce qu’il a à faire reste un principe fondamental de son utilisation à ne pas négliger ».

Externalisation et centralisation de la configuration au niveau de grinder.properties

Mettre toute la configuration de vos scripts dans le fichier grinder.properties vous permettra de regrouper l’ensemble des paramètres d’une manière centralisée: «  un seul fichier à maintenir ». Vous disposez nativement de la méthode «  grinder.getProperties ()«clé» pour récupérer les valeurs des différentes clés (pas besoin d’une classe utilitaire avec un java.util.Properties.load()).

Gestion des exceptions

N’hésitez pas à renforcer vos tests par des blocs de try / catch afin de passer le test précédemment exécuté ou encore celui qui est en cours d’exécution en « fail ».

Il faudra également distinguer les erreurs techniques liées au traitement de la requête par le serveur (serveur injoignable, http code = ! 200,…) des erreurs fonctionnelles liées à la logique du déroulement du scénario (jeu de données invalide, des inputs introuvables, rendu de la page incohérent,…).

Ci-dessous une manière de faire:

import sys, traceback
request = Test(1, "Basic request").wrap(HTTPRequest(url = "http://localhost:7001"))
     try:
        result = request.GET("index.html")
     except:
        # mark the test as a failure
        grinder.statistics.forLastTest.success = 0
        # tracer l’erreur d’origine:
        grinder.getLogger().error("Unexpected error: %s: %s: %s" % (sys.exc_info()[0], sys.exc_info()[1], traceback.print_exc()))
        # throw new ExceptionTechnique
        raise ExceptionTechnique(« message d’erreur »)
     # Si le traitement dans le bloc try est exécuté
     # correctement, on vérifie que le status du dernier test est
     # OK, et que le code retour http == 200
     else:
        # récupérer l’objet Statistique pour le dernier test
        statisticsForTest = grinder.statistics.forLastTest
        # Si le test s’est terminé avec succès  et
        # http reponse code == 200
        if statisticsForTest.success and
           statisticsForTest.getLong("httpplugin.responseStatus")
           == 200:
            try:
               Dérouler votre checkList sur le rendu attendu
            except:
               # mark the test as a failure
               grinder.statistics.forLastTest.success = 0
               # tracer l’erreur d’origine:
               grinder.getLogger().error("Unexpected error: %s: %s: %s" % (sys.exc_info()[0], sys.exc_info()[1], traceback.print_exc()))
               # throw new ExceptionFocntionnelle :
               raise ExceptionFonctionnelle(« message d’erreur »)
        # sinon : erreur lors du traitement de la requête
        else:
            # mark the test as a failure
            grinder.statistics.forLastTest.success = 0
            # throw new ExceptionTechnique
            raise ExceptionTechnique(« message d’erreur »)

Parsing XML et XPath:

Le parsing xml de la réponse constitue une étape quasi-évidente pour dérouler votre check-list sur les éléments attendus et également pour récupérer les valeurs de certains d’entre eux ; ainsi, vous pourrez savoir s’il est possible de passer à l’étape suivante de votre scénario.

En terme de technologie adoptée, je vous laisse faire votre choix entre l’utilisation des APIs standards fournies avec le JDK (javax.xml.parsers, org.xml.sax, javax.xml.xpath) et l’API vtd-xml qui est plus puissante et moins consommatrice (basée sur la technique Virtual Token Descriptor (VTD))

Accès concurrents aux ressources « statiques »

Si vous manipulez des variables statiques dans vos scripts python, vous êtes sûrement face à un problème d’accès concurrentiel du moment que vous avez plus d’un injecteur sur une même JVM (grinder.processes>1).

On reconnaît ce cas de figure par le positionnement du mot clé « global » sur une variable précédemment déclarée dans le script, dans le but de pourvoir modifier sa valeur (accès en écriture) à l’intérieur d’une méthode :

maVariable = 0
   def incrementMaVariable() :
      global maVariable
      maVariable += 1

Pour remédier à ce problème, la solution la plus évidente consiste clairement à éviter d’employer ce genre de pratique qui n’est pas en phase avec l’architecture distribuée de The Grinder.
Néanmoins si vous y tenez, il est possible d’utiliser la classe Lock du module threading.py:

import threading
# récupérer un 	Object Lock pour la gestion d'accès concurrent à la ressource " maVariable "
lock = threading.Lock()
maVariable = 0
    def incrementMaVariable() :
       try:
           # will block if lock is already held
           lock.acquire()
           # lecture de la variable
           global maVariable
           # écriture de la variable
           maVariable += 1
       finally:
           # release lock
           lock.release()

Nommage des transactions et unicité des identifiants de test

Pensez à nommer vos transactions d’une manière homogène et ordonnée ; cela vous facilitera la lecture des résultats de test par la suite.
Le modèle suivant pourrait apporter un certain confort de lisibilité et de clarté : SC-<Référence du scénario>-STEP-<Numéro de la transaction>)<Libellé de la transaction>

Prenons par exemple le scénario « consultation du profil », composé de trois transactions à savoir : login, consulter profil et logout.
Cela aurait donné quelque chose de ce genre lors de la définition des tests:

request1 = Test(1, "SC-CONSULTATION-PROFIL-STEP-1)Login")
request2 = Test(2, "SC-CONSULTATION-PROFIL-STEP-2)Consultation du profil")
request3 = Test(3, "SC-CONSULTATION-PROFIL-STEP-3)Logout")

Les identifiants de vos tests doivent être uniques dans un scope «grinder-project» ; cela vous permettra d’une part d’établir rapidement le lien entre le test id et son libellé, et d’autre part d’éviter toute confusion de transaction (un même identifiant pour deux transactions différentes, bien qu’il soit toujours possible de les distinguer par le libellé).

N’optez pas pour des variables statiques (avec un système d’incrémentation), vous risquez de vous replonger dans le problème d’accès concurrents à partir du moment où vous êtes dans le cas d’une configuration multi-process par JVM; à la limite gardez-les en dur.

Intégration dans le Build PipeLine

Il existe un plugin Hudson : http://wiki.hudson-ci.org/display/HUDSON/Grinder+Plugin:

Ce plugin permet d’exécuter les scripts « grinder » pendant le build et d’inclure les résultats de tests obtenus dans le rapport hudson.

Génération des rapports graphiques

Il existe principalement deux outils :

• Grinder Analyzer : Permet de parser les logs grinder et de générer des rapports graphiques (au format html). L’utilisation de cet outil reste très simple et suffisante  pour un aperçu visuel des résultats lorsqu’il s’agit d’un environnement de test mono-agent et mono-worker. Cependant, il trouve rapidement ses limites face à des données  issues de plusieurs « agents » et « workers », ou également lorsqu’il s’agit de générer des graphiques de comparaison entre deux tests.
  • Démo: http://track.sourceforge.net/example/report.html
• ground-report : Produit un ensemble de rapports graphiques (rapport de synthèse, rapport individuel par test, rapport de comparaison entre plusieurs tests,…) au format pdf et à partir d’une base de données PostgreSQL. Il est également possible de produire des rapports au format rtf, xml  ou xhtml.
  • Démo: http://ground.sourceforge.net/samples.html
  • Il se distingue par :
    • La qualité de ses rapports.
    • Configuration rapide.
    • La sauvegarde des résultats de test en base de données garantissant ainsi d’avoir l’historique de l’ensemble tests.
    • Son « ToolKit » pour les opérations d’injection des données « grinder » en base.

Les limites

• Ne produit pas nativement des graphiques.
• Ne permet pas de simuler des sessions à partir d’adresses IP différentes, ce qui constitue  généralement un point très important lorsque le target system  est « load-balancé » (souvent le cas en production).
• Manque du support.

Conclusion

Dans la mesure où les tests de performance s’imposent de plus en plus, comme c’est le cas actuellement pour les tests unitaires, les tests d’intégration et les tests fonctionnels qui ne cessent de se greffer dans nos projets, il me semble envisageable de compléter la stack de test en faisant d’eux une partie intégrante des projets; ce qui nous permettra de les faire constamment marier aux évolutions que subissent les applications.

Aujourd’hui on parle d’un test unitaire cassé, on pourrait bien parler d’un script de test de charge cassé.

Pour peu que l’on ait conçu et développé ses scripts proprement (sans pour autant frôler la limite de l’over-design), on gagne énormément en maintenabilité: modifier le comportement d’un script, c’est comme si l’on s’apprêtait à modifier une  méthode d’un service.

Le fait que The Grinder s’appuie sur du Jython (implémentation de Python en Java),  on garde toujours un même environnement d’exécution; que ce soit du .java  vers du .class ou du .py vers $py.class jusqu’au runtime, c’est toujours la JVM qui bosse. En plus, vous continuez à profiter de toutes les API Java; ce qui vous offre le moyen de rester dans vos habitudes et de ne pas forcément glisser dans une démarche full-python.

• Collections classiques
• Respect de l’ordre d’insertion
• Respect de l’ordre naturel

Collections classiques

Commençons par la star de ces dames : ArrayList. Comme toute List qui se respecte, cette implémentation est une séquence d’objets autorisant les doublons, la valeur null et l’ajout à un index donné. Elle est bâtie sur un tableau dont la taille est gérée en interne.

légende : e = élément, i = index, n = nombre d’éléments

Cette liste est donc toute désignée lorsqu’il s’agit d’itérer sur des éléments ou d’y accéder par index. Mais, dès lors qu’une suppression ou une recherche est nécessaire, il faudra s’en remettre à une autre collection ; pourquoi pas au matheux de la bande : HashSet. Cet ensemble ne tolère ni doublons, ni valeur null ni accès à un élément donné. Il permet, cependant, de vérifier la présence d’un élément en son sein ou de l’en retirer en temps constant.

légende : c = capacité (c > n)

Cet ensemble serait la collection idéale si il offrait la possibilité d’accéder à un élément par index. Il n’en demeure pas moins un alié de choix lorsque l’appartenance d’un élément prime sur la valeur de ses attributs. Si ces deux informations comptent, c’est à sa soeur ainée qu’il faut s’adresser : HashMap. Ce dictionnaire référence ses objets par clé (à l’image du rangement d’une définition par mot dans un dictionnaire classique). L’ajout d’un objet pour une clé existante remplace l’ancien objet.

légende : k = clé (de type objet)

Attention toutefois, les objets clés sont transformés en entier à l’aide d’un algorithme de hash (la structure sous-jacente peut être vue ainsi Map<int, Objet>). Ce calcul est effectué à partir de la référence java de l’objet ; deux objets aux attributs égaux ne correspondent pas à la même clé. Il est possible de modifier cet état de fait via la surcharge des méthodes hashCode() et equals() (« Effective Java » souligne que les deux méthodes doivent toujours être implémentées de paire). Les wraps de type primitifs les surchargent par défaut (deux Integer de même valeur représentent la même clé).

Comme le souligne la JavaDoc, la complexité des types à base de hash est garantie à condition que la fonction de hash répartisse correctement leurs valeurs. Les collisions sont prises en charge ; lorsque deux objets aux attributs différents obtiennent le même hash, ils sont tous deux conservés. Si la fonction de hash est correcte, n opérations s’effectuent en O(n), les erreurs étant amorties par le nombre d’éléments, une opération est bien en O(1).

En Java les hash sont couramment calculés ainsi, pour n attributs a : ((17 * 31 + a1) * 31 + a2) * ... * 31 + an 31 offre les qualités d’être un nombre premier, impair et de permettre une multiplication optimisée 31 * i == (i << 5) - i Et, toujours selon « Effective Java », ce nombre offre une bonne distribution (HashCodeBuilder de commons-lang s'appuie lui, par défaut, sur 37). La valeur initiale 17 diminue le nombre de collisions qu'aurait occasionné un premier attribut de valeur 0. Sa valeur est arbitraire.

Respect de l'ordre d'insertion

Certaines implémentations des collections sont dédiées au maintient des éléments dans leur ordre d'insertion.

À l'instar du HashSet, les opérations du LinkedHashSet sont en temps constant. Ses performances sont légèrement moins bonnes (à cause du coût de maintient du tri), à une exception : itérer sur ses éléments sera moins coûteux (relatif à son nombre d'éléments et non à sa capacité).

Ces mêmes remarques s'appliquent à LinkedHashMap, respectant elle aussi l'ordre d'insertion.

En ce qui concerne les listes, ArrayList maintient déjà les éléments dans leur ordre d'insertion, mais des compères peuvent lui prêter main forte dans certains cas particuliers.

légende : ajout en queue, retrait en tête

Comme ses paires, la liste doublement chainée LinkedList n'est pas allouée d'un bloc ; ses éléments se référencent les uns les autres. Récupérer un élément à un index donné peut être coûteux si l'on ignore son prédécesseur ou son successeur (LinkedHashSet et LinkedHashMap ont recours à ce procédé pour garantir l'itération ; chaque élément connait le suivant).

Une ArrayDeque peut être utilisée comme une file d'attente ; premier arrivé, premier servi (FIFO). Elle peut également l'être comme une pile d'assiettes ; dernière arrivée, première utilisée (LIFO). Cette implémentation est à préférer à celle de Stack, basée sur Vector. Comme elle n'accède qu'aux premier et dernier éléments, cette implémentation offre une suppression en temps constant.

Respect de l'ordre naturel

Certaines implémentations des collections sont dédiées au maintient des éléments dans leur ordre naturel (les chiffres et les chaines de caractères par ordre croissant, les objets selon leur implémentation de l'interface Comparable) évitant d'avoir recours à un tri.

Un TreeSet peut remplacer avantageusement un ensemble classique lorsque des éléments y sont ajoutés à différentes reprises et que leur ordre importe.

Une TreeMap permet de s'assurer de l'ordre d'itération sur ses clés.

Une TreeList, proposée dans commons-collections car absente du langage natif, améliore suppression et vérification d'appartenance d'un élément au détriment d'une insertion plus coûteuse. Sa documentation souligne que LinkedList est rarement un bon choix (via des statistiques que l'on aimerait voir plus souvent ; TreeList vs ArrayList vs LinkedList).

Limite des collections du JDK

Malgré sa richesse, certains cas de figure ne sont pas adressés par les collections du JDK. C'est là qu'Apache avec ses commons-collections et Google avec guava-collections (anciennement google-collections) prennent le relais. Contrairement aux secondes, et malgré leur popularité, les premières ne supportent pas les génériques (un portage de la version 3.1 par une entreprise externe les y ajoute ; mais ne semble plus maintenu). Voici leurs dépendances maven : guava-collections, commons-collection (et de son port en collections-generic).

Retenir une collection pour sa complexité en temps n'a pas que des vertus d'optimisation, elle est porteuse de sens pour l'algorithme qu'elle accompagne ; elle porte plus que l'opération elle-même la logique des traitements attendus.

Ce billet est dédié à Denis Lapoire

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/.

Pour rappel, nous avions laissé notre utilisateur unique avec un temps mirobolant de 1,7 secondes par requête en moyenne.

Le tableau ci dessous montre que la concurrence est nuisible à nos temps de réponse.

La base une ressource critique.

Première amélioration, quasiment gratuite. En allant chercher dans les problèmes que nous avions mis de coté (il y a quelques semaines sur le blog, mais quelques minutes auparavant lors du Xke , nous pouvons exhumer le traçage de la totalité des requêtes SQL dans les fichiers de log. Cette fonctionnalité est bien connue des utilisateurs d’Hibernate (très pratique pour débugger), mais elle se retrouve malheureusement bien trop souvent en production.

<prop key="hibernate.show_sql">false</prop>

Il suffit alors d’une simple modification dans la configuration d’Hibernate, d’un redéploiement, et miracle, les temps s’améliorent déjà un peu.

• hibernate.show_sql à false
• Temps moyen de 8,2 s à 7,6 s pour 5 utilisateurs
• 1 point pour l’équipe qui a trouvé

Après cette correction facile, attaquons nous à plus complexe.

Si la montée en charge induit une augmentation du temps de réponse, c’est que les utilisateurs sont en concurrence sur un certain type de ressource, ou bien qu’ils mettent la machine à genoux. Un rapide coup d’oeil dans VisualVm nous montre que la CPU et la mémoire ne sont pas saturées, on a donc à faire à une contention applicative.

Celles ci peuvent être de deux types :

• une concurrence applicative, mal gérée avec les outils fournis par java.concurrent.util
• une contention sur des ressources externes, comme un pool de connexions JDBC dans une DataSource.

Comme nous étions déjà sur Hibernate dans la correction précédente, continuons à creuser le sillon. Et profitons en pour dégainer un nouvel outil de notre couteau suisse de diagnostic : JMX.
Pour vérifier si nos connexions JDBC sont bloquantes, utilisons l’api de monitoring de Java. Une fois de plus, utilisons notre VisualVm, qui propose une interface graphique d’affichage des MBeans.
Nous sommes chanceux, nos GO ont utilisé la dataSource standard de Tomcat, elle est donc exposée Catalina:type=DataSource,class=javax.sql.DataSource,name="jdbc/petclinicMySQL"

En procédant par sondage rapide (à l’aide de la fonction ‘refresh’ du MBean), on constate rapidement que les valeurs maxActive et numActive se rejoignent autour de la valeur 3. Pas la peine d’en dire beaucoup plus… Comme d’habitude, la documentation va nous confirmer ce que nous pouvions supposer à la lecture de ces valeurs. maxActive nous donne le nombre maximal de connexion JDBC, alors que numActive nous donne celles qui sont utilisées à l’instant t. Ce qui signifie que lorsque les 3 connexions sont prises, les process suivant se mettent en attente, pendant un temps fixé par maxWait soit 3 secondes. Le goulet d’étranglement est évident. Il suffit donc de le fluidifier.

Ce paramétrage se trouve dans la configuration du serveur tomcat, dans le fichier server.xml. Nous allons agir sur deux paramètres : le maxActive, que nous allons positionner à 30 connexions (ce qui est plus que raisonnable) et sur le maxWait afin de ne pas attendre en vain une connexion qui ne viendra jamais.

<GlobalNamingResources>
    <Resource name="jdbc/petclinicMySQL" auth="Container" type="javax.sql.DataSource" driverClassName="org.gjt.mm.mysql.Driver" url="jdbc:mysql://localhost:3306/petclinic_light?autoReconnect=true" username="petclinic" password="petclinic" maxActive="30" maxIdle="10" removeAbandoned="true" removeAbandonedTimeout="60" logAbandoned="true" maxWait="60"/>
</GlobalNamingResources>

Les résultats sont immédiats et nous passons à un temps moyens de 7,2 s :

• Paramétrage de la datasource
• Temps moyen de 7,6 s à 7,2 s pour 5 utilisateurs
• 2 points pour l’équipe qui a trouvé

Ca coince toujours. Où le temps est il consommé ?

Pas la peine d’envisager de passer à plus d’utilisateurs tant que le temps moyen de requête est aussi catastrophique. Si l’on s’intéresse plus en détail aux résultats de JMeter, on constate que la requête Owner detail est la plus consommatrice. Sûrement quelque chose à optimiser de ce côté là.
On ne va pas déroger aux bonnes habitudes prises, on retourne dans VisualVm. Et quand quelque chose coince au niveau applicatif, on réalise un ensemble de ThreadDump. Comme nous sommes avides de nouveauté, nous allons laisser les commandes Unix vi et grep aux dinosaures et utiliser les possibilités de VisualVm, à savoir le plugin Tda.

Pour mettre en évidence notre problème, nous allons tout d’abord restreindre les scenarii JMeter à la seule et unique requête Owner Details. Ensuite, nous allons réaliser une série de ThreadDump très rapproché (de 5 à 10 en quelques secondes). Nous allons ensuite utiliser une des possibilités de TDA, à savoir la détection des Thread longue durée Long Running Thread. TDA va tenter d’identifier les threads ‘bloqués’ dans la même méthode au travers de n ThreadDump.
Comme auparavant, nous ne nous occuperons que des catalina-exec-xx RUNNABLE. Et nous avons de la chance, puisque sur nos cinq utilisateurs, nous trouvons 2 threads bloqués au même point, dans la même méthode (vous l’aurez compris, la détection de thread longue durée est principalement basée sur un ‘coup de sonde’ statistique).

Un petit tour dans le code, dans la classe incriminée.

/**
     <strong> Custom handler for rendering images.
     </strong>
     <strong> @param petId
     </strong>            the ID of the pet whose visits to display
     <strong> @param response to output the image bytes
     </strong> @throws IOException
     */
    @RequestMapping(value = "/owners/*/pets/{petId}/image", method = RequestMethod.GET)
    public void petImageHandler(@PathVariable int petId, HttpServletResponse response) throws IOException {
        int imgId = petId % 6;
        InputStream in = Thread.currentThread().getContextClassLoader().getResourceAsStream("img/pet-" + imgId + ".jpg");
        response.setContentType("image/jpeg");
        OutputStream out = response.getOutputStream();
        IoUtils.copy(in, out);
        clean();
    }

A priori, rien de très suspect dans la façon de servir des images stockées côté serveur (le but de l’exercice n’étant pas d’éliminer le problème, en changeant le comportement de l’application et en déplaçant ces images côté apache).
Si on revient à nos ThreadDump, nous constatons que nous pouvons encore descendre dans le code, à l’intérieur de la classe IoUtils.

    public static void copy(InputStream in, OutputStream out) throws IOException {
        OutputStream bufferedOutputStream = new BufferedOutputStream(out);
        byte[] buffer = new byte[512];
        int length;
        while ((length = in.read(buffer)) >= 0) {
            bufferedOutputStream.write(buffer, 0, length);
        }
        bufferedOutputStream.close();
    }

A priori, si les copies d’InputStream / Outputstream étaient à ce point sous performantes, cela se saurait. Mais ne mésestimons pas la fourberie de nos poseurs de bombes.

En y regardant de plus près, on constate en effet que nous avons une belle implémentation maison de la méthode write, inspirée de celle du ByteArrayOutputstream.

public synchronized void write(int b) {
            int newcount = count + 1;
            if (newcount > buf.length) {
                buf = Arrays.copyOf(buf, (buf.length << 1) / 2 + 3);
            }
            buf[count] = (byte) b;
            count = newcount;
        }

Et là où le ByteArrayOutputstream se redimensionne de manière intelligente pour accélérer la copie

    public synchronized void write(int b) {
	int newcount = count + 1;
	if (newcount > buf.length) {
            buf = Arrays.copyOf(buf, Math.max(buf.length << 1, newcount));
	}
	buf[count] = (byte)b;
	count = newcount;
    }

, l’implémentation maison reste définitivement bloquée et recopie les octets 2 à 2…

Si nous remplaçons cette implémentation par java.io.BufferedOutputstream, nous devrions avoir de bien meilleurs résultats.

Et en effet cette fois, c’est spectaculaire. Pour nos cinq utilisateurs, nous passons à un temps moyen de 1,4 s avec une très remarquée dégringolade du temps moyen de ownersDetail qui passe de 32 s à 3,7 s.

• Suppression d’un java.io maison
• Temps moyen de 7,2 s à 1,4 s pour 5 utilisateurs
• 3 points pour l’équipe qui a trouvé

Il va bientôt être temps de passer à un nombre d’utilisateurs « raisonnable ».

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/category/filiere-java-jee/.

Cette soirée gratuite vous permettra d’appréhender les bonnes pratiques que se doivent de respecter les Directions Etudes et Développement pour rendre leurs applications Java/J2EE prêtes pour la production.

Elle se déroulera dans les locaux de Xebia : 156, boulevard Haussmann, 75008 Paris.
Les inscriptions peuvent se faire :

• Par mail : info@xebia-training.fr
• Par téléphone : 01.53.89.99.93
• En ligne sur le site de Xebia Training

Les technologies Java ont été massivement adoptées par les DSI pour la réalisation de leurs applications critiques. Porteuses de valeur et d’innovation, elles posent régulièrement problème au niveau des départements Exploitation/Production. Instabilité chronique, manque de capacité à monter en charge, difficultés de diagnostiques en cas de dysfonctionnement, déploiement chaotique sont autant de maux fréquemment rencontrés par les entreprises utilisatrices.

Les bonnes pratiques que se doivent de respecter les Directions Etudes et Développement pour rendre leurs applications Java/J2EE prêtes pour la production s’articulent autour des axes suivants :

Les bonnes pratiques pour le déploiement

Le déploiement est le baptême du feu d’une application en production. Comment réussir cette épreuve ?

• Complexité des composants à déployer : simplicité rime avec fiabilité,
• Les paramètres de configuration : éviter l’anarchie,
• Traçabilité et build automatisés : maitriser sa plateforme.

Les bonnes pratiques de robustesse

Dans l’adversité, une application robuste assure un service minimum plutôt que de s’arrêter :

• Dépendances inter-application : fail fast est il synonyme de fragilité ?
• Prévention des saturations et des effets “domino” : l’art du code défensif,
• Modes dégradés : les négociation technico-fonctionnelles.

Les bonnes pratiques pour la supervision et le monitoring

Une application en production doit exposer son état aux équipes d’exploitation et faciliter la détection de problèmes :

• Indicateurs de bon fonctionnement d’une application : ne pas se noyer dans les chiffre,
• Comment exposer les indicateurs de performances ? Fichier de log versus page JSP versus Java Management eXtension (JMX) ?

Les bonnes pratiques de log

Grande source d’incompréhension entre les départements études et exploitation, les logs d’application Java ? Quels formats de messages ?

• Codes erreurs chers aux exploitants, exceptions chainées et stacktraces familières aux développeurs, quel compromis ?
• Des logs de troubleshooting extrêmement verbeuses aux logs d’audit sécurité à conserver plus d’un an en passant par celles de perfs et celles de diagnostique, comment organiser les logs ?

Les bonnes pratiques organisationnelles

Avoir une application prête pour la production ne se limite pas à des bonnes pratiques techniques, la collaboration des départements études et exploitation est essentielle :

• Prendre en considération les réalités de production dans les développements : une amélioration continue,
• Les incidents : comment s’y préparer pour qu’ils ne se transforment pas en longues indisponibilité.

BONUS

Les bonnes pratiques de robustesse

• Les mécanismes de ré-essai

• 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.

Après une première passe qui nous a permis de calibrer les logs de manière un peu plus pertinente, il est temps, toujours sans l’aide du code source, de mettre les mains sous le capot de Tomcat (6.0.20).

Et pour cela, rien de mieux que de jeter de nouveau un œil à notre VisualVm.

Tant de threads pour un seul utilisateur.

Pour (re)commencer, penchons nous sur nos threads, juste après le démarrage du serveur (et donc avant la première connexion d’un utilisateur)

Lorsque l’on démarre un serveur Tomcat, un certain nombre de threads sont affectés à sa ‘tuyauterie’ interne (connecteurs RMI, JMX). Mais de là à avoir 165 threads, il y a certainement un souci quelque part !
Creusons un peu, et entrons dans le détail de ces threads en utilisant l’onglet Threads.

Hormis les threads ‘connecteurs’ de Tomcat, on voit apparaître 150 threads catalina-exec. Ces threads sont en charge des traitements des requêtes HTTP, via le HTTP-8080-acceptor. Nous avons donc, « à froid » 150 unités d’œuvre prêtes à traiter nos requêtes. Sachant que pour l’instant nos tests se limitent à un utilisateur, on sent que nous sommes très légèrement surarmés par rapport à nos besoins.
Tomcat ne devrait-il pas gérer automatiquement ces problématiques de montée ou descente en charge ?
Allons faire un petit tour dans la documentation, du côté du connecteur HTTP.

Si nous recherchons le paramètre minSpareThreads dans nos fichiers de configuration, nous le trouvons dans server.xml. Repassons le à une valeur plus réaliste de 10 threads, sachant que Tomcat montera automatiquement en charge si besoin.
Cela n’a pas d’impact visible sur les performances, mais au moins, les ThreadDumps deviennent lisibles (obfusquer les ThreadDumps était le but recherché de ce paramétrage).
Autre paramètre qui a interpellé les connaisseurs de Tomcat, la classe de l’Executor. org.apache.catalina.core.extended.PrestartingThreadExecutor n’est pas une classe courante. D’habitude, on utilise plutôt le StandardThreadExecutor. Une fois encore, on peut remercier nos buggers en chef : PrestartingThreadExecutor est une classe custom, qui démarre automatiquement tous les threads HTTP. De nouveau, l’impact sur les performances est négligeable pour un utilisateur, mais mieux vaut laisser Tomcat gérer toutes les problématiques de vie du serveur d’application. Sans vouloir leur faire offense, nos maîtres de cérémonie n’ont pas le niveau des équipes Apache rodées à l’exercice depuis de très nombreuses années
Dernier paramètre « malin » introduit au niveau de Tomcat, le paramètre -Xss. Celui-ci peut être découvert via l’overview de VisualVm. -Xmx, -Xms sont des paramètres classiques (nous reviendrons dessus) que grand nombre de développeurs connaissent. Mais -Xss ? Comme d’habitude, notre meilleure arme est la documentation de Sun.

-Xssn
    Set thread stack size.

Avons nous réellement besoin d’une taille de stack de 1024 Ko ? Difficile à dire, surtout a priori. Mais une fois encore, le plus simple est de faire confiance à Tomcat, quitte à devoir intervenir a posteriori. Nous ne sommes plus à un redémarrage près.

Maintenant que notre application est déployée et paramétrée de manière à peu près correcte, il est temps de rentrer « dans le dur » : mettre les mains dans le cambouis et explorer le code source.

Fuite mémoire, threads dump, ça explose de tous les côtés.

Dès que nous avons eu le code source entre les mains, plusieurs stratégies se sont dégagées :

• la première consiste à conserver un seul utilisateur dans les scripts JMeter et à le pousser à faire plus d’itérations,
• la seconde consiste à mettre plus d’utilisateurs JMeter en parallèle.

Toujours dans le but de rester très didactique, nous allons appliquer la première stratégie. Qui trouve rapidement sa limite :

Aux environs de la 70ème itération, la heap used tangente la heap max, le Garbage Collector est déclenché plusieurs dizaines de fois par seconde de manière totalement inefficace, et la JVM finit par faire un joli OutOfMemory. Les symptômes classiques de la fuite mémoire.

Comment faire pour la trouver ?
C’est à la fois simple et complexe : depuis la JVM 6, il est très facile, grâce à VisualVm de réaliser des « photographies » exhaustives de la mémoire de la JVM, les célèbres heap dumps. Malheureusement, ce n’est possible que sur les JVM locales.
Conformons nous donc à l’énoncé et n’installons pas notre Tomcat en local. La solution consiste à utiliser la commande jmap.
Commençons par générer un histogramme, que nous allons filtrer.
jmap -histo <pid_jvm> | grep org.spring
Notre premier candidat arrive en 16ème position dans l’histogramme :
16: 14000 560000 org.springframework.samples.petclinic.Vet
14 000 vétérinaires, voilà qui est surprenant… De là à dire que notre fuite tourne autour de cet objet métier, il n’y a qu’un pas. Malheureusement, à part en allant dans le code à la pioche, il va être difficile de colmater la fuite avec aussi peu d’information. De nouveau, jmap va nous rendre service, cette fois en générant un heap dump.
jmap -dump:format=b,file=/tmp/dump.hprof <pid_jvm>
Pour exploiter ce dump, nous avons choisi d’utiliser l’outil Eclipse Mat. Dès l’ouverture, Mat nous propose de rechercher les leak suspects
Et là, le diagnostic est assez évident.

Un type d’objet monopolise à lui seul 92 % de la mémoire. Il ne reste plus qu’à creuser dans le heap dump pour déceler l’allocation coupable.
Passons donc à la vue dominator tree. En dépliant progressivement la pile mémoire (en cliquant sur l’objet qui a la plus grande retained heap), on constate que la mémoire est occupée par de très nombreuses occurences de org.springframework.samples.petclinic.util.CacheFilter$CacheEntry

Maintenant que nous avons un coupable, il est temps, pour la première fois, d’ouvrir notre code source sous Eclipse. En faisant une simple recherche de classe sur notre coupable désigné, nous arrivons au code suivant :

HttpSession session = request.getSession();
Map<String, CacheEntry> cache = (Map<String, CacheEntry>) session.getAttribute("pages.cache");
if (cache == null){
    cache = new Hashtable<String, CacheEntry>();
    session.setAttribute("pages.cache", cache);
}
...
//Return cached content if available
String path = context.getRealPath("") + request.getRequestURI() + request.getQueryString();
CacheEntry cacheEntry = cache.get(path);
if (cacheEntry != null) {
    response.setContentType(cacheEntry.t);
} else {
    //Else, fetch it
    cacheEntry = new CacheEntry();
    CacheResponseWrapper wrapper = new CacheResponseWrapper(response);
    chain.doFilter(request, wrapper);
    byte[] buf = cacheEntry.buf;
    InputStream in = wrapper.getContentAsInputStream();
    OutputStream out = cacheEntry.c;
    int length;
    while((length = in.read(buf)) >= 0) {
        out.write(buf, 0, length);
    }
cacheEntry.t = wrapper.getContentType();
cache.put(path, cacheEntry);
}

Chaque page est donc mise en cache dans la session de l’utilisateur. Le timeout du cache étant fixé à l’infini, on voit de manière assez évidente que chaque fois que notre JMeter lance une campagne de test, il ouvre une nouvelle Session dans laquelle l’ensemble des pages vues est gardée en mémoire (avec un taux de réutilisation proche de zéro).
L’utilisation des ressources mémoire de notre JVM est ici particulièrement mauvaise.
Deux solutions sont envisageables :

• basculer le cache dans un scope application. Mais dans ce cas, attention, la taille de celui-ci peut vite exploser et l’utilisation d’un filtre qui cache systématiquement tout le contenu de la réponse peut rapidement échapper à tout contrôle.
• supprimer purement et simplement ce cache dont le taux de hit est ridiculement bas. C’est la solution que nous choisirons ici, car c’est la plus économique (une ligne à commenter dans le web.xml).

Cette correction ne devrait toutefois pas affecter notre nombre élevé de Vets trouvés via l’histogramme… Nous y reviendrons probablement.

Ne reste alors plus qu’à re-construire (via Maven) et relivrer l’application pour voir le résultat.

Cette fois, le gain de performance ne se mesure pas directement dans JMeter. Les temps de réponse de l’application sont sensiblement identiques à ce qu’ils étaient avant nos interventions.

En revanche, nous avons largement gagné en performance dans deux domaines :

• le plus immédiat, celui du ressenti utilisateur : plus la peine de rebooter notre serveur tous les 70 scenarii, et ça toutes les équipes d’exploitation vous le diront (sauf les mauvais élèves qui ont bêtement automatisé leurs redémarrages), c’est un énorme gain.
• celui plus égoïste, d’avoir des traces propres et peu nombreuses, donc beaucoup plus exploitables.

Pour finir, les points attribués :

• Fuite mémoire de CacheFilter en session
• Passage de la barre des 70 scenarii pour 1 utilisateur
• 2 points pour l’équipe qui a trouvé

Comme l’a très bien pressenti l’un de nos lecteurs (voir les commentaires sur l’article précédent), nous ne sommes pas encore au bout de nos surprises

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

A Devoxx, deux sessions étaient dédiées au thème du tuning de performance en Java : Performance for the performance-shy par Holly Cummins et The not so dark art of performance tunning par Kirk Pepperdine et Dan Hardiker. Nous nous attardons ici sur cette dernière.

Kirk Pepperdine (photo ci-contre) est Java Champion et possède une expertise reconnue dans le domaine des performances des applications Java. On se souvient également de sa présentation en avril 2008 au ParisJUG où il avait fournit un aperçu des problématiques liées à ce sujet.
Dan Hardiker est pour sa part le fondateur d’une entreprise spécialisée dans l’hosting de solutions basées sur Confluence.

La session qu’ils ont tous deux présentée à Devoxx ne se voulait pas exhaustive sur le sujet de la performance, bien trop vaste et complexe pour être traité en une heure, mais cherchait surtout à mettre en avant des principes et des attitudes à adopter.

Les anti-patterns de tuning de performance

La session commence avec la présentation de deux anti-patterns couramment rencontrés lors des procédures d’amélioration de performance. Ces anti-patterns avaient été formalisés il y a trois ans par Kirk Pepperdine : l’absence de test de montée en charge (No stress testing) et le tir à l’aveugle (Shot in the dark).

Aucun test de montée en charge

Il s’agit là d’un cas courant : une application, un nouveau système ou simplement une mise à jour majeure est mise en production sans avoir effectué le moindre test de montée en charge. L’estimation de la viabilité de l’installation se faisant alors sur l’expérience passée et la réactivité de l’application lors des phases de recette.

Bien sûr cela peut très bien se passer. Mais dans certain cas, il en résulte une pure et simple indisponibilité de service due à un écroulement des performances ayant entraîné une saturation des serveurs.

Les tests de montée en charge sont indispensables pour connaître et éventuellement corriger par avance les limitations des applicatifs que l’on va mettre en production.

Tir à l’aveugle

Il s’agit là également d’un comportement courant, mais conduisant à des actions inefficaces voir erronées. Lorsqu’un problème de performance est constaté, l’équipe en charge de l’application fait quelques suppositions et procède immédiatement à des ajustements en conséquence.

Là encore, ce type de comportement peut conduire à une résolution du problème, mais la procédure manque de précision et peut mener à une aggravation de la situation ou à des solutions mal maitrisées et difficilement explicables.

Lorsqu’un problème de performance est constaté, seule la prise de mesure permet de mettre en œuvre des corrections sérieuses car décidées en toute connaissance de cause.

Les causes d’augmentation du temps de réponse

Il est important de connaître les points pouvant être responsables de l’augmentation du temps de réponse au sein d’un système. Si l’on considère un système 3 tiers classique, les localisations de ces points sont nombreuses :

De part la nature distribuée de l’architecture 3 tiers, le temps de réponse est en général consommé autour de l’envoi des requêtes et de la réception des réponses. Cette latence peut alors être causée par l’OS, la JVM, le middleware ou par l’application. Il est important de considérer l’ensemble de ces acteurs.

Les outils de diagnostic

Kirk Pepperdine et Dan Hardiker ont également présenté deux outils très courants et simples d’utilisation pour faciliter le diagnostic des applications présentant des problèmes de performances :

• VisualVM : cet outil très populaire est disponible en standard dans le JDK depuis sa version 6.0. Il permet d’analyser le comportement du garbage collector et d’observer les métriques JMX d’un serveur d’application.
• TDA (Thread Dump Analyser) : ce plugin pour VisualVM permet d’effectuer des analyses de thread dumps. Cette analyse permet d’aider à localiser les locks ou les parties de code consommant la majorité du CPU en montrant l’activité de chaque thread d’une JVM à un instant donné.

Conclusion

A Devoxx, il est toujours intéressant d’observer la fréquentation des différentes sessions. Si le succès de certains sujets tels que JEE 6, Spring 3.0, Maven 3.0 ou encore JDK7 est très facilement prévisible, celui du tuning de performance en Java est moins évident à priori. Pourtant les deux sessions dédiées à ce sujet ont fait salle comble. Cette tendance montre que ce sujet concerne beaucoup de monde mais reste peu maitrisé…

L’approche de Kirk Pepperdine et Dan Hardiker présentée ici est intéressante car ils s’efforcent de considérer la problématique des performances d’un point de vue global : alors que le développeur se focalise principalement sur son code pour améliorer les performances d’une application, il est nécessaire de considérer la question de la performance à tous les niveaux – l’application, le middleware, la JVM, la base de données, le matériel, le réseau – pour être efficace. En ce sens, la performance est une problématique globale et non locale.

Les lecteurs intéressés par ce sujet noteront que Kirk Pepperdine proposera pour la première fois en France, une formation en Janvier à Paris où il aura l’occasion de développer en détail les connaissances théoriques et pratiques liées au tuning de performance en Java.

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.

• Cache distribué: l’ensemble des données est réparti sur les différents nœuds qui composent le cluster Coherence. Afin de garantir une bonne tolérance aux pannes, les données peuvent être sauvegardées sur un ou plusieurs nœuds du cluster. Cette typologie est extrêmement extensible : il suffit d’ajouter des nouveaux nœuds pour augmenter la capacité globale du cache.
• Cache répliqué: l’ensemble des données est répliqué sur l’ensemble des nœuds du cluster. La modification d’une entrée sera propagée à l’ensemble des nœuds. Cette typologie permet d’offrir un accès très rapide en lecture car un seul nœud est sollicité dans l’opération. La contre-partie est que les opérations d’écriture sont lentes et que la taille du cache est indépendante du nombre de nœuds qui composent le cluster.
• Cache local: les données sont conservées exclusivement sur la JVM.
• Near Cache: il permet d’offrir le meilleur des caches de type ‘Répliqué’ (Performance) et de type ‘Distribué’ (Extensibilité) en fournissant un accès rapide aux données accédées le plus fréquemment et le plus récemment. Il est composé de 2 parties:
• le ‘front-cache’ pour les accès locaux, de petite taille, typiquement un cache Local (Local Cache),
• le ‘back-cache’ un cache de plus grande envergure, typiquement un cache distribué (Distributed Cache), qui contient l’ensemble des données avec leurs éventuelles sauvegardes.

Le point fort d’Oracle Coherence est de proposer la même API quelque soit le type de cache. Il est donc possible, par simple configuration, de modifier le type de cache et de l’adapter en fonction des besoins ou de l’environnement: cache local en « Développement », cache distribué en « Intégration », « Near » cache en « Production ».

En première approche, l’API d’Oracle Coherence est extrêmement simple : elle se résume à obtenir une Map et à la manipuler par les opérations habituelles: put(), get(), keySet(), entrySet()….

import com.tangosol.net.CacheFactory;
Map cache = CacheFactory.getCache("moncache");        //1. Récupération d'une instance de cache,
cache.put("benoit","moussaud");                       //2. Ajout d'un élément dans le cache
String name = (String)cache.get("benoit");            //3. Recherche par sa clé d'un élément dans le cache
assert name.equals("moussaud");

Le type de cache est déduit du nom du cache. Il est configuré dans le fichier coherence-cache-config.xml inclus dans coherence.jar. Par défaut, les règles suivantes sont appliquées:

Si l’on veut appliquer ses propres règles, il faut définir son propre fichier de configuration et indiquer son emplacement au lancement de Coherence avec la propriété système tangosol.coherence.cacheconfig.

La suite de l’article va montrer comment interroger un cache Coherence autrement que par une clé dans une Map.

Un service de recherche de communes…

Prenons un service qui permet de rechercher l’ensemble des communes françaises en précisant le début de leur nom.

public interface CatalogService {
	public List<Commune> getCommuneByName(String name);
}

Une implémentation classique est de créer une table ‘COMMUNE’ dans une base de données, d’y insérer les ensembles des communes de France (38206 dans mon exemple) avec leur libellé, un code postal et un code Insee, et d’effectuer la requête SQL SELECT ID, DEP_CODE, CODE_INSEE, LIBELLE FROM COMMUNE where LIBELLE like #name#.

Voici le résultat d’un benchmark du service avec pour paramètre la première lettre de la commune (de A à Z)

Benchmark Base de données

Le temps de réponse du service est mauvais et proportionnel au nombre de communes retournées

…Coherence à la rescousse…

La première idée est de placer le résultat de la recherche dans un cache avec pour clé le paramètre de recherche. Ce type de conception est efficace seulement si le nombre de filtres est fini, par exemple s’il résulte d’une sélection d’une combo-box dans une page web. Si la valeur du filtre est moins contrainte, le service sera appelé par un grand nombre de filtres différents et donc le cache risque d’être peu efficace (à moins de disposer d’une mémoire infinie de manière à conserver toutes les requêtes !).

La seconde idée est de charger dans un cache l’ensemble des communes et d’effectuer une recherche directement dans le cache. L’API Coherence offre la notion de Filter

public class CatalogServiceWithCoherence implements CatalogService,
     private final NamedCache cacheCommunes = CacheFactory.getCache("Commune");
     public List<Commune> getCommuneByName(String name) {
         Filter filter = new LikeFilter("getName", name + "%", false);
         return performSearch(filter);
     }
     @SuppressWarnings("unchecked")
     private List<Commune> performSearch(Filter filter) {
         Set<Map.Entry<Object, Commune>> entrySet=cacheCommunes
                 .entrySet(filter);
         List<Commune> result = new ArrayList<Commune>(entrySet.size());
         for (Map.Entry<Object, Commune> e : entrySet) {
             result.add(e.getValue());
         }
         return result;
     }
}

Appliquons le même benchmark.

Résultat du benchmark Coherence avec Filtre

Le temps de réponse du service est meilleur (autour de 500 ms) mais constant. Il y a donc un gain par rapport aux requêtes qui retournent beaucoup d’éléments (A,B,C,L,S,..) mais une perte sur les requêtes qui retournent peu d’éléments. Donc plus le filtre sera sélectif, moins la recherche dans le cache sera efficace.

Ceci se comprend mieux si on affine l’étude de l’API Coherence. L’interface Filter définit une seule méthode: evaluate

package com.tangosol.util;
public abstract interface Filter
{
  public abstract boolean evaluate(Object paramObject);
}

Donc une recherche dans le cache par filtre se résume à parcourir l’ensemble des entrées de la Map et à appliquer le filtre passé en paramètre.

…Encore plus rapide avec un index

Si on examine de plus près le filtre utilisé LikeFilter, on peut noter qu'il implémente l'interface IndexAwareFilter. Il est donc possible d'indexer le contenu d'un cache Coherence. Le code ci-dessous ajoute un index au cache "IndexedCommune": pour chaque entrée ajoutée au cache, il va extraire et indexer la valeur de la propriété "Name" (getName()).

NamedCache cache = CacheFactory.getCache("IndexedCommune");
cache.addIndex(new ReflectionExtractor("getName"), true, null);

Appliquons le benchmark.

Benchmark Coherence avec filtre indexé

Avec l'ajout de l'index, le temps de réponse du service a encore nettement chuté et reste proportionnel au nombre de communes retourné. Donc si le filtre est sélectif, le temps de réponse sera très bon.

En moyenne, la première solution a divisé le temps de réponse par 5, la seconde par 80. Cependant il faut garder à l'esprit qu'un accès à une valeur par son index (cache.get(key)) reste beaucoup plus performant que l'utilisation des Filters. Leurs utilisations doivent rester des exceptions.

Conclusion

Les solutions de "Data Grid" modernes comme Oracle Coherence offrent maintenant des services de haut niveau, semblables à ceux offerts par des SGBD, comme la gestion de la concurrence, des transactions, des indexs, du partitionnement, qui permettent d'améliorer nettement les performances d'une application J2EE.

Sources

Vous retrouverez l'ensemble des sources présentées dans ce billet dans le repository SVN de Xebia France.

Références

• Oracle Coherence (Site Officiel)
• Les caches, ces armes à manipuler avec précaution
• Paris JUG : Soirée Data Grid le 12 mai
• Oracle Coherence Knowledge Base Home

Incohérences des données, est-ce un problème ?

C’est probablement l’une des phobies les plus répandues dans le monde informatique, partagées aussi bien par les développeurs, les architectes que les clients : l’incohérence des données. Phobie compréhensible puisque les données représentent la valeur ajoutée même de votre métier, sans elles, pas de transactions donc pas de rentrées d’argent. Et pourtant, nous constatons trop souvent que cette phobie est le point de départ de bien des problèmes. Combien d’usines à Shadocks ont été montées à tort ? Combien de fausses bonnes idées ont coulé des projets ? Ceci vient souvent d’une mauvaise interprétation des besoins du client : la perte ou l’incohérence des données est dans bien des cas acceptables. Alors, pourquoi s’obstiner à se rajouter systématiquement des aiguilles dans la poupée vaudou de votre projet.

En résumé, les problématiques liées à la cohérence des données d’un cache distribué sont les mêmes que celles d’une source de données partagée telle qu’une base de données : mises à jour concurrentes, échecs de mise à jour, fiabilité des contraintes… L’ajout d’un cache distribué n’est donc pas anodin, vous rajoutez avec lui une complexité complémentaire à votre système.

Stratégies de notifications, mises à jour synchrones ou asynchrones

En cas de modification locale d’un élément d’un des caches d’un cluster, deux solutions s’offrent à vous pour répercuter celle-ci sur les différents nœuds de votre cluster :

• par copie, vous envoyez un message contenant le nouvel objet (ou un différentiel de celui-ci)
• par invalidation, vous envoyez une notification demandant aux autres membres du cluster d’effacer tout ou partie de leurs caches liés à cet élément.

Si vous êtes le seul à connaître l’existence d’un élément (i.e. l’objet a été créé localement et n’est directement disponible dans aucune source de données), vous n’avez d’autre choix que de propager vos modifications par copie. Dans tous les autres cas, c’est à vous de choisir la meilleure option en fonction du type de vos données.

Il est souvent recommandé de privilégier les mises à jour par copie. Celles-ci évitent le rechargement complet des caches de votre cluster. Suivant le type de données, vider entièrement un cache peut s’avérer désastreux : l’invalidation peut provoquer une demande massive d’objets simultanée à partir des différents nœuds d’un cluster. Les caches regroupent souvent des données homogènes dont les objets sont liés les uns aux autres. Il est facile de noyer la base sous une pluie de requêtes gourmandes en ressources et simultanée. Le but premier de votre cache distribué n’était pas de limiter les accès à la base de données ? Cet effet est encore amplifié par la fréquence de mise à jour de vos données. Dernier conseil, une mise à jour par copie perd de son intérêt lorsque que la durée de vie maximale des objets de vos caches est faible, surveillez votre time-to-live.

Pourtant, la mise à jour par copie n’est pas sans risque, vous exposez vos objets à de potentielles désynchronisations d’états entre les différents nœuds de votre cluster. En effet, la majorité des mécanismes de mise à jour par copie n’assurent pas la réussite de celle-ci. Par exemple, si une micro coupure réseau intervient lors de la demande d’une mise à jour d’un objet entre 2 serveurs, il est courant de constater qu’au final les deux objets ne soient pas identiques. (il en est d’ailleurs le même pour les mécanismes d’invalidation). Si les mécanismes de copies asynchrones sont rapides, ils ne garantissent pas la bonne exécution de leur service. Au contraire, d’autres mécanismes synchrones le permettent, mais à quel prix pour vos utilisateurs ? Êtes-vous prêt à stopper l’activité de votre serveur en attendant d’obtenir les accusés de réception de l’ensemble des nœuds de votre cluster.

Attention au Cache L2 Hibernate

Lorsque l’on sort le Cache L2 de la trousse à outils, on en attend souvent un résultat miraculeux. Pourtant, si cette solution est simple à mettre en place, elle n’est pas magique pour autant. Il est donc important d’en connaître les principales caractéristiques.

Les manipulations de données des caches s’effectuent le plus souvent par l’ajout ou la récupération d’un seul et unique objet. Les caches proposent tous une manipulation simple par le biais de ces simples méthodes : cache.put( Element element ) pour l’ajout d’un objet dans le cache et cache.get ( Object key ) pour la récupération. Et ce sont ces mêmes méthodes que le cache L2 Hibernate va utiliser. Ainsi, la mise à jour du cache, quelque soit son implémentation, va passer par une mise à jour objet par objet. Ceci s’avère peu performant lorsque le cache doit mettre à jour de volumineuses listes d’objets.

Vous l’avez compris, les effets peuvent vite devenir catastrophiques en cas de mauvaise utilisation des associations Hibernate. Il est parfois pertinent d’utiliser un système de cache externe sans utiliser le cache L2 Hibernate. Afin d’appuyer cela, je vous invite à lire le billet de blog suivant dans lequel l’auteur effectue une comparaison des performances en fonction des différentes utilisations du cache dont voici les résultats :
Pour 50 objets chargés contenant chacun 2 relations One-To-Many

• Hibernate Simple sans cache : 192 secondes
• Hibernate avec un cache L2 basé sur Ehcache : 60 secondes
• Accès direct à Ehcache, utilisation d’Hibernate pour les objets non trouvés dans le cache : 20 secondes
• Accès direct à Ehcache, utilisation d’Hibernate pour les objets non trouvés dans le cache et optimisation du nombre d’ouvertures de sessions : 1 seconde

Le caching, ce n’est pas si simple

Ce billet n’avait pas pour but de lister l’ensemble des problématiques liées aux caches distribués, j’en suis d’ailleurs incapable ; mais juste de mettre en lumière les principales problématiques liées au caching. Qu’il soit distribué ou non, la mise en place d’un cache ne doit pas s’effectuer à la légère. Si elle est censée améliorer les performances, elle en augmente grandement l’entropie de votre système. C’est pourquoi il est nécessaire d’avoir les moyens d’estimer le gain de performances lié à la mise en place de vos caches. La majorité des API proposent pour cela de la consultation des statistiques via JMX. Compter le nombre de hits (éléments tirés du cache) et de misses (éléments non trouvés dans la cache) vous permettra d’évaluer facilement le rendement de celui-ci.

Si vous ne deviez retenir qu’une chose, un cache c’est comme un pare-chocs de voiture pour une base de données :

• Mal placé, ça sert à rien
• Mal configuré, c’est inefficace

Attention aux accidents

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