Revue de Presse Xebia

La revue de presse de l’actualité Java/J2EE hebdomadaire proposée par Xebia.

Agilité

• Discipline et agilité

Le coin de la technique

• Fragmentation mémoire et JVM, compactez votre ‘Gros Tas’
• Indiscrétions sur Maven 2.1.0
• Améliorer les performances de Tomcat en production
• Mockito s’offre un lifting.
• Java EE 6 et ses RI
• Des nouvelles de Java SE 7 …

Agilité

Discipline et agilité

Dans cet article, Claude Aubry nous rappelle que l’agilité possède des règles à respecter. En effet nombreux sont ceux qui pensent que l’agilité permet de faire face aux imprévus plus rapidement. Ce n’est pas tout le temps le cas, car l’agilité possède des règles qu’il faut respecter (gestion du backlog, des priorités…) afin que les sprints se déroulent dans de bonnes conditions.

Le coin de la technique

Fragmentation mémoire et JVM, compactez votre ‘Gros Tas’

Si la description des différents algorithmes de Garbage Collection se trouve relativement facilement sur le Web, peu décrivent comment ceux-ci gèrent la fragmentation de la heap. Même si la durée de vie des objets est en moyenne très courte (dans une application de gestion), la JVM ne peut échapper à la gestion d’objets plus gros dont la durée de vie est plus importante. La fragmentation de la mémoire est inévitable. On estime que celle-ci peu atteindre facilement 10% de la mémoire pour des applications 24/7 et par conséquent peut être la cause d’OutOfMemory.
Dans son article Ghost in the Java Virtual Machine, Nick Maiorano nous décrit les différents mécanismes de compaction dont sont tirés ces grands principes.
Deux principes de compaction :

• Garder une trace des fragments et les réallouer dès que c’est possible. Ceci implique le déplacement d’objets et la mise à jour des objets les référençant. Cette opération n’est rendue possible que lors d’un Full GC. Second problème, avec ce mécanisme, il se peut que deux objets créés simultanément se référençant l’un l’autre soient dispatchés sur deux pages physiques de la mémoire.
• Copier les objets vivants dans une autre part de la mémoire en les agençant les uns après les autres. Avec cette méthode la mémoire est constamment réorganisée et les objets se retrouvent concentrés dans une même zone de la mémoire, ce qui peut améliorer les performances.

Nous vous laissons consulter le reste de l’article comparant le fonctionnement des algorithmes de compaction des JVM JRockit de BEA et Hotspot de Sun.

Indiscrétions sur Maven 2.1.0

Deux articles intéressants sur le blog de Brett Porter, commiteur Maven.
Un article sur la mise en ligne de Maven 2.1.0 milestone 1, avec une liste de quelques fonctionnalités qui seront ajoutées à cette version (en plus de meilleures performances).
Et un article sur le plugin reactor, qui apporte quelques fonctionnalités que l’on devrait retrouver intégrées de base à Maven 2.1. Le scénario suivant est donné en exemple: un build de 10 minutes plante au bout de 9 minutes à cause d’une erreur sur une dépendance. L’erreur est corrigée, et le plugin reactor permet de reprendre le build là où il a planté. Sympathique!

Améliorer les performances de Tomcat en production

La configuration par défaut de Tomcat répond à la plupart des besoins en production. Il est en outre facile de tuner légèrement le serveur d’application afin d’optimiser les performances de celui-ci.
Filip Hanik et Mark Thomas nous donnent quelques pistes dans leur Webinar hébergé par SpringSource.
Nous listerons ici les principaux faits marquants de cette optimisation, vus à travers 3 grands sujets (nous ne traiterons volontairement pas ici les optimisations de JVM, plus « convenues »).

Tuning des logs

• Le fichier catalina.out de sortie de la console (java.util.logging.ConsoleHandler) a pour limitation de ne pas offrir de rotation. Il y a donc un risque d’overflow. On peut remplacer ce handler par un org.apache.juli.FileHandler (rotations quotidiennes) ou un java.util.logging.FileHandler (rotations par date ou au volume de fichier pour prévenir la saturation des disques).
• Le logger par défaut est synchrone, ce qui peut devenir un goulet d’étranglement. L’utilisation d’un logger asynchrone peut donc améliorer les performances mais aucune implémentation n’est incluse dans Tomcat.

Tuning HTTP et TCP/IP
Avant de s’attaquer à ces améliorations, il est important de comprendre les protocoles TCP / IP, le fonctionnement du CPU et les concepts de load balancing.

• Sessions TCP : Http Keep alive permet d’améliorer les temps de réponse en évitant quelques handshakes TCP ; cependant, l’accroissement de la consommation de ressources serveurs peut nuire aux sites à forte concurrence d’accès.
• TCP Flow Control : bien que l’API Servlet repose sur des IO bloquantes, Tomcat optimise le service du contenu statique avec les connecteurs NIO et APR, grâce à la méthode non bloquante SEND_FILE.
• Principaux paramètres à configurer :
       – maxThreads : typiquement entre 200 et 800, 400 étant une bonne valeur initiale.
       – maxKeepAliveRequests : typiquement entre 100 et 200 (SSL, APR / NIO connector) ou 1 pour désactiver « Keep Alive » (pas de SSL, BIO connector, très forte concurrence, etc).
       – acceptCount (backlog TCP) : typiquement entre 50 et 300.
       – connectionTimeout (SO_TIMEOUT), le temps maximum entre deux paquets TCP : entre 2000 à 3000 ms est souvent optimal, même en activant Keep Alive.

Quel connecteur choisir?
Cela dépend des besoins de l’application :

• Blocking IO Connector :
       – La majorité du contenu est dynamique
       – Keep-Alive n’est pas important
       – La fiabilité est une priorité
• Apache Portable Runtime/APR Connector :
       – Tomcat gère l’encryption SSL : l’implémentation SSL d’APR (Open SSL) est beaucoup plus rapide que celle des JVM et les handshakes SSL non bloquants améliorent les performances
       – Keep-Alive est important
       – Une grande partie du contenu est statique
       – La fonctionnalité Comet de Tomcat nécessite un connecteur non bloquant (APR ou NIO)
• NIO Connector :
       – Connecteur non bloquant comme l’APR connector
       – A la différence de l’APR connector qui nécessite la librairie native APR, le NIO connecteur est portable sur toutes les plateformes
       – Le NIO connector ne bénéficie par de l’optimisation SSL apportée par Open SSL
• AJP Connector :
       – Déconseillé, il n’est pas plus performant que les connecteurs HTTP et est en revanche difficile à troubleshooter.

Dans le doute, utiliser le connecteur BIO (le plus mûr, qui ne crashera pas et qui auto gère le keep alive)

Contenu statique

• Les connecteurs APR et NIO offrent l’optimisation SEND_FILE
• Tomcat offre un cache (e.g. <Context cacheMaxSize="40960" cacheTTL="60000" cachingAllowed="true"> ) du contenu statique. Cependant, cette fonctionnalité ne rivalise pas avec un proxy cache comme Squid ou mod_cache )

Mockito s’offre un lifting.

Si vous appliquez les 10 commandements des tests unitaires (cf point 7), la sortie de la version 1.5 de Mockito devrait vous apparaître comme une bonne nouvelle.

Principale différence entre ce framework et ses concurrents (EasyMock et JMock), Mockito peut se passer d’expectations et vérifier le comportement d’un objet à posteriori. Cette fonctionnalité permet de considérablement réduire la taille du setup des tests, et de les rendre plus lisibles.

De plus, comme Mockito possède une syntaxe très similaire à celle d’EasyMock, il est facile de refactorer quelques tests pour l’essayer, et pourquoi pas l’adopter.

Java EE 6 et ses RI

Cette semaine, Antonio Goncalves, membre de l’expert group des JSR Java EE et co-fondateur du Paris Jug , nous rappelle l’arrivée prochaine de Java EE 6 début 2009 et récapitule la liste des principales implémentations de références des différentes briques et ses spécifications :

Une preview de Java EE 6 a d’ailleurs été effectuée ce mois-ci au Priceton JUG dont voici le résumé. Une session également en préparation au Paris JUG, elle est pour le moment prévue pour janvier prochain.

Des nouvelles de Java SE 7 …

Ah non, fausse alerte ! Point d’Umbrella JSR à l’horizon …