Tag :Performance

Parlons perf avec Ludovic Poitou!

Blog de Ludovic Poitou Le Lyon JUG accueille, le 17 janvier prochain, Ludovic Poitou pour un talk intitulé Performance des serveurs en Java : l’expérience du projet OpenDJ. Ludovic Poitou est chef de produit sur OpenDJ, un serveur d’annuaire LDAP écrit en Java, et directeur de ForgeRock France. Il a travaillé en tant qu’ingénieur de développement pendant 15 ans chez Sun Microsystems où il fut Architecte des produits d’annuaire et Community Manager du projet OpenDS, un service d’annuaire open source en Java. Agnès Crépet et Alexis Hassler, tous deux membres de la team du Lyon JUG ont posé quelques questions à Ludovic, pour vous mettre l’eau à la bouche avant sa session à Lyon !

Agnès & Alexis: Peux-tu te présenter? Quel est ton parcours professionnel et quelles sont tes activités aujourd’hui au sein de ForgeRock?

Ludovic: Bonjour, je m’appelle Ludovic Poitou et je suis chef de produit chez ForgeRock. J’ai une formation universitaire : un Magistère en Informatique et Sciences de l’Ingénieur, obtenu à l’Université de Nice Sophia Antipolis (formation qui existe encore sous l’enseigne Polytech Sophia-Antipolis après s’être appelée ESSI). J’ai commencé ma carrière dans une startup dans le domaine des serveurs de messagerie et d’annuaires, E3X, rachetée par TéléSystèmes puis Sema (maintenant Atos). En 1995, j’ai été embauché comme développeur logiciel chez Sun au centre Recherche et Développement de Grenoble, où j’ai principalement travaillé sur les serveurs d’annuaire LDAP, aussi bien au niveau produit (Sun Directory Server) que standardisation à l’IETF, ou sur l’évangélisation de projets open sources comme OpenDS.
Après 15 ans, et suite au rachat par Oracle, j’ai rejoint ForgeRock en tant que chef de produit pour les produits d’annuaire et le projet OpenDJ, et directeur du centre recherche et développement en France, basé à Grenoble.

Agnès & Alexis: Tu vas aborder la problématique des performances en Java dans ta session pour le LyonJUG. Question simple pour commencer : imaginons que je me rende compte un matin que mon application que j’ai mise en production la semaine dernière s’exécute de plus en plus lentement sur son serveur Tomcat. Quels sont les outils que tu utilises pour mesurer les performances d’une application Java en production, et quels sont les métriques sur lesquels tu vas particulièrement te concentrer ? Au niveau de la JVM, Quels sont les règlages à faire en priorité dans ma JVM ?

Ludovic: Tout d’abord, je vais parler de performances du serveur en Java, et pas des applications qui tournent dans un serveur d’application, tel que Tomcat. Mon expérience s’appuie sur le projet OpenDJ, qui est un serveur d’annuaire LDAP écrit en Java. Dans notre cas d’utilisation, nous avons deux critères principaux : le nombre d’opérations exécutées par secondes, et le temps de réponse. Pour mesurer cela, nous avons nos propres outils de charge LDAP qui produisent des statistiques en temps réel, mais aussi les statistiques du serveur lui-même.
Et dès qu’il s’agit de commencer à regarder comment se comporte la JVM, nous utilisons les outils standards Java, en priorité le log du Garbage Collector, et JConsole.
Donc, au niveau de la JVM, les premiers réglages sont définir la taille minimum et maximum de la JVM et activer le log du GC.

Agnès & Alexis: Le garbage collector G1 est apparu assez récemment. Est-il vraiment mature, début 2012 ? Est-ce qu’il doit devenir le GC par défaut, remplaçant tous les autres ? En particulier, le CMS a-t-il encore un raison d’être ?

Ludovic: Lorsque je travaillais encore chez Sun (avant Septembre 2010), nous étions en relation régulière avec l’équipe HotSpot et plus particulièrement Tony Printezis qui développait G1. Notre serveur d’annuaire avait été intégré dans une suite de tests automatiques de toutes les JVMs, et a énormément servi pour stresser G1, principalement avec des JVM de 16 à 64 GB. Nous avions d’ailleurs des versions de développement de la JVM pour nos propres tests, qui se révélaient prometteurs. Mais avec le rachat par Oracle et la réorganisation qui s’en ait suivi, j’ai l’impression que G1 a été mis de coté temporairement. Les quelques tests que nous avons fait avec les dernières mises à jour de Java 6 et avec Java 7 à sa sortie n’ont pas été probants.
Par contre, nous avons vu une flopée de correctifs sur G1 apportés dans Java 7 update 2 et nous sommes encore en train de faire des tests pour voir si G1 peut être utilisé en production.
Pour résumer, mature, probablement pas encore. Et donc CMS a encore des raisons d’être.

Agnès & Alexis: Que penses-tu de la suppression annoncée du Perm Space (inspirée de JRockit et de la JVM d’IBM) dans les releases à venir de la JVM V7? Pourquoi était-il utile par le passé et plus maintenant ?

Ludovic: Le PermGen Space est un espace mémoire de la JVM qui sert/servait à stocker les méta-données concernant les classes utilisateurs. Sa taille est devenu un problème récurrent avec tous les serveurs d’application qui chargent et déchargent les classes des applications. Personnellement, avec OpenDJ, nous ne nous en sommes jamais vraiment préoccupés.
Ces méta-données sont toujours nécessaires, et donc elles ont été déplacées de la pile Java à la pile native. Cela permet de simplifier la tache du GC, mais va obliger les administrateurs à surveiller la taille du process natif pour éviter que la JVM swappe.

Agnès & Alexis: Récemment au lyonJUG nous avons proposé une session “Architecture stateful vs stateless”. En terme de performances, penses-tu qu’une architecture stateless soit réellement plus scalable qu’une architecture stateful (notamment parce qu’on s’évite le problème de synchronisation de sessions entre plusieurs serveurs)?

Ludovic: J’avoue ne pas avoir vraiment d’opinion sur le sujet, ni de réelle expérience. Le protocole LDAP est un protocole connecté et qui garde l’état d’authentification. Donc nous sommes obligatoirement amenés à travailler en stateful.

Agnès & Alexis: Le “scale-out” est-il plus efficace que le “scale-in” pour une application Java ?

Ludovic: Cela dépend vraiment de l’application et de son modèle.
Si on regarde les serveurs d’annuaires, ils sont construits autour d’une base de données spécialisée (un B-Tree) et donc sont plus orientés scale-up. Mais depuis longtemps, le scale-out est disponible pour les opérations de lecture grâce a la réplication des données, souvent une fonctionnalité intrinsèque au produit.
OpenDJ est donc dans un modèle scale-up, avec une réplication multi-maître pour la disponibilité.
Sun Directory Server, le serveur sur lequel je travaillais avant OpenDS et OpenDJ, est déployé chez quasiment tous les opérateurs télécom avec plusieurs dizaines de millions d’utilisateurs, le plus gros ayant 120 Millions d’entrées dans leur service d’annuaire. Nous avions fait un “Proof of Concept” de scale-out pour un client qui voulait un annuaire avec 420 Millions d’entrées, en distribuant les données sur plusieurs serveurs d’annuaires et une couche de proxy LDAP pour faire le routage. Les résultats étaient impressionants en terme de performance, mais le coût hardware de la solution rédhibitoire !

Agnès & Alexis: Tu vas nous parler d’OpenDJ . Peux-tu présenter brièvement cette solution? Comment se démarque-t-elle d’autres solutions comme Apache Directory ou OpenLDAP. Ayant démarré comme un fork d’OpenDS, comment les deux solutions évoluent-elles en parallèle aujourd’hui?

Ludovic: OpenDJ est un serveur d’annuaire LDAP écrit en Java, qui est très complet fonctionnellement, offre de très bonne performances, mais surtout est simple à déployer et administrer. Au départ, il a été conçu chez Sun Microsystems pour remplacer le produit Sun Directory Server, écrit en C (hérité de Netscape Directory Server), mais qui avait une conception datant de plus de 15 ans.
Par rapport à Apache Directory, OpenDJ est vraiment orienté entreprises, avec un aspect qualité et fiabilité mais surtout conçu pour de gros volumes avec des besoins de performance.
Par rapport à OpenLDAP, OpenDJ apporte de la simplicité, la portabilité grâce à Java (le serveur et ses données sont indépendants du matériel et de l’OS). Et une compatibilité ascendante, surtout au niveau réplication, ce qui permet de faire évoluer les serveurs sans interruption de service.
Pour ce qui est d’OpenDS, les équipes qui travaillaient dessus chez Oracle ont été redéployées, et le projet n’évolue plus. Oracle a sa propre fork propriétaire et a annoncé un produit basé sur OpenDS : Oracle Unified Directory. Ce qui en fait le 4eme produit d’annuaire chez Oracle, et je doute de leur stratégie a ce sujet.
De notre coté, le développement d’OpenDJ continue en open source, et une grande partie de la communauté d’OpenDS nous a rejoint. Nous avons d’ailleurs eu plus de contributions en 2011 que pendant les 4 ans de développement d’OpenDS.

Agnès & Alexis: Vous avez pris le parti de sortir fréquemment des releases OpenDJ. Quel est votre processus d’intégration et de livraison (outils, méthodes)?

Ludovic: Depuis le début d’OpenDS, notre usine logicielle s’appuie sur Ant. Nous utilisons Jenkins CI pour l’intégration continue et les tests automatiques. Nous avons près de 30000 tests unitaires, écrits avec TestNG, qui sont lancés à chaque build et encore quelques milliers de plus la nuit. Nous avons toute une suite de tests fonctionnels (environ 2800 tests) qui sont exécutés aussi toutes les nuits dans un framework basé sur Stax.
Le cycle de livraison est celui que nous utilisions chez Sun. Préparation du build et vérification par les suites de tests automatiques, puis suit une phase de tests par l’équipe de QA pour couvrir certains aspects comme le GUI, les tests de conformité LDAP, de stress…
Enfin, la mise en place sur le site web est manuelle. OpenDJ est disponible sur forme de Zip, de package SVR4 (pour Solaris) mais aussi avec un installeur en Java Web Start. Et avec la prochaine version, nous devrions rajouter les packages RPM et Debian.
Nous travaillons aussi à mettre notre processus de livraison sur Maven, afin de faciliter l’intégration avec les autres projets de ForgeRock ou d’ailleurs. Le Toolkit LDAP qui inclut une librairie LDAP cliente et des outils de tests est déjà entièrement sous Maven.

Merci Ludovic!

Les inscriptions pour la session de Ludovic au Lyon JUG le 17 janvier sont ouvertes !

Soirée Performances au Lyon JUG avec Claude Falguière

A l’occasion de la prochaine édition du Lyon JUG, le 21 décembre, Claude Falguière, bien connue du réseau des Duchess, va proposer une session autour de la stratégie de test de performance.

Claude Falguière
Claude Falguière est Architecte Technique pour la société de conseil Valtech Technology à Paris. Après plusieurs années chez un éditeur de base de données Objet comme consultant et formatrice, elle a intégré Valtech pour participer à plusieurs projets Web J2EE puis s’est spécialisée dans l’évaluation de performance applicative, l’audit et l’optimisation. Elle est membre de l’équipe du Paris JUG et Co-fondatrice de Duchess France. Découvrez son portrait sur ce site

@cfalguiere

Pour vous donner envie de venir assister à cette session du Lyon JUG, nous avons posé quelques questions à Claude, notamment sur les bonnes pratiques à mettre en œuvre lorsqu’on veut réaliser des tests de performances, et sur JMeter, l’outil qu’elle nous présentera dans sa démo
Agnès : Tu t’intéresses particulièrement aux outils et pratiques touchant aux tests de performance. Quand fait-on généralement appel à un expert comme toi ? Lorsque tout va mal? Est-ce que la plupart des clients anticipent la mise en place de tests de performances bien avant la première mise en production ? Les tests de ce type sont-ils intégrés dans un cadre de développement incrémental (une campagne de tests de performances à chaque fin de sprint ou d’itération) ?

Claude : Je suis expert performance dans une société qui n’est pas spécialisée dans le test. J’interviens donc plus en tant qu’architecte expert des problématiques de performance pour auditer les tests et l’application et trouver une solution quand la campagne s’est mal passée. Il y a souvent des problèmes des deux côtés, dans les procédures de test et dans l’application. Pour faire simple, les applications sont souvent assez peu performantes car l’objectif est de développer vite. Et certains testeurs considèrent que le rôle est de casser l’application et non de simuler l’activité au plus juste pour déterminer si les exigences sont respectées. Dans d’autres missions, le problème de l’application est réel, identifié mais la solution demande une collaboration entre les études et l’infrastructure, ce qui n’est pas toujours possible.

J’interviens aussi de plus en plus sur des problèmes en production sur des systèmes non testés ou qui se sont dégradés avec le temps. Avec la réduction des coûts des ressources et l’amélioration de la capacité des JVM à gérer de plus gros espaces mémoire depuis Java 5, les problèmes que l’on rencontre sont différents. Dans beaucoup de cas, les applications ont des performances acceptables mais les soucis viennent de problèmes de stabilité qui apparaissent aléatoirement. Dans beaucoup de cas ce sont des dimensionnement logiciels (taille des pools, mémoire excessive, etc.) qui ne tiennent pas compte des ressources effectives de la machine. Mais on trouve aussi de plus en plus souvent des problèmes liés à la concurrence, soit par des locks qui bloquent le système, soit justement par une absence de gestion de la concurrence et donc des corruptions de données au niveau des services qui finissent par empêcher l’application de fonctionner.

Comment on en arrive là ? Parce qu’il y a une différence entre choisir une architecture performante, des frameworks performants, mettre en place des mécanismes de gestion des performances et appliquer les bonnes pratiques et le résultat effectif. Accumuler des éléments performants ne fait pas toujours un système performant s’ils sont mal utilisés ou mal intégrés. Si une application Web génère 1500 requêtes par page, l’optimisation du framework ne changera pas grand chose. Et à cause de la fragmentation en composants ça n’est pas toujours visible dans la conception. C’est l’équivalent de considérer que parce qu’on a écrit les spécifications le système aura un bon niveau de qualité.

Ensuite les caches et autres mécanismes d’optimisation répondent à des problématiques particulières et sont complexes à configurer correctement. J’ai vu des applications armées de tout un tas de mécanismes d’optimisation qui rendaient le système instable, de caches de requêtes sur des données jamais relues, qui marchaient beaucoup mieux une fois que l’on enlevait tout ça.

Pour les performances, l’inconvénient du tir à vue c’est qu’il complexifie le système. Et plus le système est complexe plus on aura du mal à comprendre pourquoi il ne marche pas comme on s’y attend.

On a appris à tester les fonctions de manière itérative et même via les tests unitaires en continu. La différence entre le test fonctionnel et le test de performances est que l’on peut tester du fonctionnel de manière relativement isolée. Les performances sont définies en charge, pour l’ensemble du système d’un point de vue fonctionnel et sur une plate-forme technique bien définie. Donc si on veut être strict d’un point de vue Assurance Qualité on ne peut tester que juste avant la mise en production.

Il faut aussi ajouter un aspect financier. Le test de performance est entièrement automatisé, très sensible aux évolutions de l’application et entraîne des coûts importants de maintenance de ces scripts. D’autant qu’ils sont souvent faits avec des outillages maitrisés seulement par quelques personnes.

On a là les trois raisons qui font que les tests sont souvent réalisés trop tard :
– un excès de confiance sur la qualité du système
– une impossibilité de garantir la qualité du système partiellement, et donc tant qu’il n’est pas fini
– des coûts importants de maintenance des scripts

Pour pouvoir tester de manière itérative il faut sortir de cette vision rigide, sortir de la contrainte du système iso-fonctionnel, iso-production. Pour cela, il faut accepter que le test ne garantisse pas la qualité du système, mais garantisse qu’on n’ait pas trouvé un certain nombre de défauts qui empêcheraient d’atteindre de bonnes performances.

Pour préparer l’application au test de qualification et à la production, on va définir une série de tests non-qualifiants, exploratoires (parce qu’on ne sait pas quel critère appliquer au résultat que l’on va produire) ou dont l’objectif est limité, et répartir ces tests sur l’ensemble des itérations.

On peut commencer assez tôt sur des tests en baseline en travaillant sur les consommations de ressources, les tailles de page, les nombres de requêtes générées. Ces valeurs ne sont pas impactées par le dimensionnement du système et seront déterminantes pour la capacité du système à monter en charge. Certes ces tests ont un coût, mais livrer un système avec 6 mois de retard pour résoudre des problèmes de stabilité et de performances inacceptables a aussi un coût.

Sur une plate-forme non conforme les temps de réponse sont faux, mais l’application se comporte de la même manière si le but du test est de vérifier si le système se comporte de manière robuste face à des pannes ou des saturations de ressources, il n’est pas nécessaire d’avoir exactement la plate-forme cible

On peut aussi dans le cadre de la préparation du test final, tester seulement un scénario même si cela n’est pas représentatif car un autre scénario pourrait perturber celui ci. Cela permet de comprendre où sont les goulets d’étranglement de cette fonction

Bien identifier des objectifs de tests permet de les planifier au plus tôt en fonction de la disponibilité de l’application et de la plate-forme, et donc de trouver des défauts possibles au plus tôt. On évite aussi de s’épuiser en voulant refaire le plan de test de performance complet tous les mois.

Agnès : Une bonne pratique pour mener à bien des tests de performances est de limiter les écarts entre la production (“la vraie vie”) et le contexte des tests de performances? Sur quels points portent principalement les écarts?

Claude : Le test de performance n’est qu’une simulation, une expérience en éprouvette (une grande éprouvette). On va réunir tous les indices possibles sur, mais ce qu’il fait n’est jamais la vrai vie et faire différence introduit un biais.

Les biais potentiels sont partout.
Sur la plate-forme cible : les machines, les équipements réseaux, les versions de logiciels, les configurations de logiciels (activation de fonctions de compression ou de gestion de cache), les volumétries dans la base de données, les temps d’accès disque.
Sur ce que font les utilisateurs, comment ils le font, combien font-ils chaque type d’action, à quel rythme, la navigation qu’ils utilisent, les valeurs plus ou moins précises qu’ils utilisent en critère de recherche, la répartition des produits qu’ils consultent (sur des sites de commerce, il y a souvent 10% des produits beaucoup plus consultés que d’autres).

Des tas de biais, des tas de litiges potentiels en fin de course et donc il faut mettre tout ça à plat dès le départ.

Il faut distinguer deux choses :
– le test d’acceptance qui est une problématique contractuelle
– et les tests non qualifiants que l’on fait tout au long du projet et qui vont permettre de préparer l’application

Pour les tests de qualification, la plate-forme iso-production, iso-volume et la représentativité de l’usage de l’application sont incontournables. On accepte souvent une plate-forme partielle parce qu’on arrive à réduire le périmètre technique validés par le test et que l’écart permet d’extrapoler les résultats. Par exemple, on ignore souvent les équipement d’accès en amont des serveurs parce qu’on fait l’hypothèse qu’ils tiendront la charge. Ou on teste une plate-forme iso-production mais divisée par deux. Au delà, il faudrait utiliser des outils très complexes à mettre en œuvre pour simuler le résultat et le jeu n’en vaut pas la chandelle.

La définition de l’usage une partie assez critique de la définition des tests de performance, à cause du principe garbage in – garbage out. Les scénarios de test influent totalement sur le résultat. On peut obtenir de mauvaises performances avec n’importe quelle application en simulant un uasge irréaliste, ou a contrario avoir des performance faussement acceptables.

Dans les tests qualifiants, ce sont les exigences contractuelles qui définissent ce qu’est la “vrai vie”. On se base souvent sur 3 critères parce que c’est une bonne approximation : les actions fréquentes (elles représenteront le bruit de fond de tout ce qui a été ignoré), les actions vitales (parce qu’il est important de s’assurer qu’elles fonctionnent) et les actions qui pourraient présenter un risque pour les autres (par exemple un exemple de recherche avancée et de rapport souvent cause de ralentissement pour l’ensemble du système). On défini aussi combien d’utilisateurs font chaque type de scénario et les valeurs variables qu’ils vont utiliser.

Même si on se rapproche autant que possible de la réalité, le test de performance reste une simulation assez artificielle. La logique du test de qualification pousse à vouloir valider qu’il n’y aura aucun défaut en production. Et ça n’est pas possible avec une simulation. D’autant que les délais accordés aux tests se réduisent et que l’on est souvent obligé de faire au plus simple.

Pour vraiment garantir les performances, il faut travailler sur la production. Il faut prendre en compte le monitoring comme fonction de l’application pour pouvoir analyser les problèmes de performance en production et corriger les configurations ou l’application.

Il ne faut pas pour autant arrêter de tester les performances. L’objectif de vérifier un certain nombre de points avant de mettre en production est sain. Ce processus ne garantie pas l’absence de tous les problèmes mais permettra déjà de corriger les plus évidents et de mettre au point le système de surveillance.

Pour les tests non qualifiants, on peut se borner à reproduire les aspects de la réalité utiles pour l’expérience. Il faut identifier chaque objectif de test, les données que l’on veut obtenir et les pré-requis en manière de plate-forme et d’usage. Dans ce cas on acceptera des écarts lorsqu’ils n’ont pas d’impact sur la situation que l’on veut tester.

Agnès : Quels sont les principaux types d’outils nécessaires pour réaliser les tests de performance, tant du point de vue du scripting et de l’exécution même, que de celui de l’analyse de résultats?

Claude : Pour les scripts et l’exécution, il faut un outil de test de performance. Je me méfie un peu des modules “performances” des outils de test fonctionnel, qui ont tendance à ne pas monter en charge.

Pour le reste, j’utilise des tas d’outils différents en fonction des informations que je veux obtenir. Le premier niveau est de collecter des métriques de base sur le système pendant le test. J’utilise en général les données récupérées le plus directement possible car cela simplifie les problèmes d’installation. Je fais installer sar quand je peux sur les linux, sinon j’utilise vmstat en boucle dans un watch, et j’ai des scripts pour collecter les informations en HTTP, JMX, SQL … selon les briques.
Pour le diagnostic, j’utilise les outils fournis par les systèmes, les données de monitoring, les logs, des outils statistiques types R pour analyser les séries de valeurs. Et je fais compléter s’il le faut.
En charge, les outils de profilage Java sont difficilement utilisables. Quelques outils comment PerformaSure s’en sortent un peu mieux, mais sont très Java EE centriques. Or le problème n’est pas toujours dans le comportement du serveur d’applications.
Lorsque l’on est dans le projet, on peut aussi utiliser des techniques plus introspectives. L’ajout des quelques traces d’alertes ou de compteurs qui permettent de mieux comprendre la répartition du temps de réponse dans les différentes couches ou services est souvent utile.

Agnès : Si on fait un focus sur l’outil que tu vas utiliser lors de ta démo, Jmeter, peux-tu nous présenter brièvement ses points forts et ses points faibles, notamment face aux mastodontes propriétaires de type LoadRunner ou SilkPerfomer?

Claude : JMeter est open source et donc sans coût de licence pour l’utilisation en charge. Il est en Java donc portable un peu partout. Il n’est pas très intuitif, mais au final il est assez flexible. Comme les scritps sont décrits par une IHM, il n’a pas de DSL. Les actions plus compliquées sont scriptables avec tous les langages supportés par la JVM. J’ai choisi de présenter celui là parce que c’est celui qui est le plus familier aux développeurs. Ce qui m’intéresse c’est de montrer les points auxquels il faut faire attention dans le test de performance, sur JMeter mais aussi sur les autres.

La mesure par un logiciel en Java peut être un problème. Les mesures de temps sont entachés par le GC. Il faut donc s’assurer que JMeter n’a pas de GC overhead.

Par rapport à d’autres outils commerciaux, les fonctions de reporting sont très limitées. J’utilise mes propres scripts en R et en Groovy pour faire les analyses et le reporting. Il a un socle pour le monitoring mais peu de composants sont fournis et permettent de mettre en place le monitoring sans trop comprendre ce qu’on fait (j’ai monitoré du Tuxedo, et j’avoue que je sais à peine comment ça marche). Il faut connaître les différents protocoles utilisés pour le monitoring, et au final ça n’est pas plus mal. ça oblige à comprendre ce qu’on fait.

Load Runner est un très beau produit, très complet et fiable, avec un très bon outil d’analyse de résultat qui me manque. Les scripts Web se codent en C et donc la difficulté est de trouver des gens qui maitrisent encore suffisamment le C pour coder les tests.

Silk Performer par exemple est un produit qui force un process (enregistrer le scénario, le vérifier, le paramétrer …). Il n’y a pas ce genre de chose dans JMeter et sans quelques bases, on ne sait pas très bien comment procéder. Mais c’est vrai aussi des process forcés par le produit car il suffit d’ouvrir la fonction de paramétrage pour que l’outil soit content.

Une des choses que j’aime dans JMeter c’est sa flexibilité surtout dans des usages plus exploratoires. Il est plus facilement scriptable. Beaucoup d’options sont configurables en ligne de commande. On peut passer les valeurs de paramètres par la ligne de commande. On a directement les résultats bruts et on peut les analyser avec ses propres outils pour les rentrer dans une intégration continue.

Agnès : En quelques mots, en synthèse, quels sont les ingrédients nécessaires à la réussite des campagnes de tests de performances?

Claude : Bien préparer ce que l’on veut faire, commencer au plus tôt même si on ne fait des campagnes en charge de vérification que tous les 1 mois ou 2, se donner les logs et les compteurs qui permettront d’analyser les problèmes, mettre autour de la table tous les gens qui peuvent trouver une solution et se parler sereinement.

Merci Claude !

Les inscriptions sont ouvertes! Rendez-vous sur le site du Lyon JUG

Devoxx 2010

devoxx10-120x240-blackDevoxx est une conférence européenne indépendante qui porte sur les technologies Java/JVM . Organisée en Belgique, à Anvers, elle nous permettra d’entendre du 15 au 19 novembre 2010 des speakers de haut niveau. Un peu moins de 3000 développeurs venant de plus de 40 pays différents s’y retrouvent chaque année.

Les conférences

Les University Days.

Les 2 premiers jours sont appelés les University Days. On y retrouve principalement des ‘University Talks’, des conférences de 3 heures qui abordent un sujet en profondeur. Il y a à chaque fois plusieurs conférences sur un même créneau horaire. Les sujets sont variés, la plupart sont techniques. Ainsi, on retrouve des sujets :

Chacun peut participer à 2 sessions de 3 heures par jour, une le matin et l’autre en début d’après midi. Ensuite, place aux ‘Tools in action’. Ce sont des petites sessions de 30 minutes qui permettent aux speakers de nous faire découvrir un outil auquel ils ont participé. Les sujets sont variés, d’une présentation de spring developer tools (que j’apprécie énormément au quotidien), à visual VM (outil de monitoring) en passant par Apache Mahout.
Entre 19 et 22h, ont lieu des BOF (Bird-of-a-Feather) qui diffèrent beaucoup de tous les autres types de conférences.
Elles réunissent peu de personnes et sont beaucoup plus informelles. Elles sont généralement menées par un ou deux speakers de manière libre. Parfois, il y a une brève présentation puis des questions, parfois ce sont des discussions ouvertes sur un sujet précis. Actuellement, le planning n’est pas finalisé sur les BOFs.

Les Conference Days

Pour les 3 jours suivants, du mercredi au vendredi, le format diffère. Les conférences  ne sont plus de 3 heures mais d’une heure : cela permet de voir bien plus de sujets différents mais de manière un peu plus superficielle. Les sujets là encore tournent autour des mêmes thèmes dans 5 salles différentes. Les sessions ‘Tools in action’ disparaissent au profit des Quickies, qui durent 15 minutes pendant la pause déjeuner.

Duchess à Devoxx

Les duchess seront présentes toute la semaine à Devoxx et plusieurs nationalités seront présentes (France, Belgique, Hollande …). Le jeudi soir, les Duchess organiseront une BoF pour discuter en petits groupes (6) autour de sujets choisis sur le thème ‘Les femmes dans l’informatique‘.

Ce que j’aime à Devoxx

Pour un prix raisonnable, Devoxx apparait comme un des principaux rendez-vous européen. Les speakers y sont accessibles et l’organisation bien rodée. En une semaine, cela permet d’améliorer fortement sa ‘culture générale Java’, surtout si l’on est débutant. Anvers n’est qu’à deux heures de Paris en Thalys, les hôtels y sont à un prix abordable. Bref, pour un investissement moyen, cela permet vraiment de progresser au niveau technique et de rencontrer énormément de monde, ce qui est toujours un avantage. Certaines SSII l’ont bien compris et y envoient chaque année plusieurs consultants.  Ceux qui n’ont pas une entreprise pour les y envoyer peuvent tout à fait se le permettre au niveau financier. Les conférences sont bien sûr des endroits où l’on apprend beaucoup, mais toutes les discussions ‘off’ pendant la pause déjeuner ou autour d’une bière le soir permettent d’avoir des retours d’expérience très intéressants.

Infos Pratiques

Au niveau de la gestion à proprement parler, pour ceux qui assiste aux University Days, deux possibilités : soit dormir sur place le dimanche soir, soit il est tout à fait possible de prendre l’un des premiers Thalys, de passer à l’hôtel si celui ci est proche de la gare et en ne perdant pas de temps de prendre le tramway pour assister aux premières sessions.
Pour les hôtels, les français semblent se regrouper cette année à deux endroits différents : l’Agora (qui devient à partir d’octobre le ‘all seasons Antwerpen City Center’) et le Park Inn qui sont tous les deux placés juste à côté de la gare. Il vaut mieux éviter de prendre les hôtels qui semblent plus proche de la salle pour deux raisons : ils sont mal desservis en transport en commun et cela veut dire également que vous ferez le chemin seul le soir et le matin.
L’année dernière, le petit déjeuner était compris dans la conférence, tout comme le repas du midi.
Au niveau du train du retour pour le vendredi, beaucoup prennent les thalys de 14h30 ou de 15h30, et certains y restent le week end pour découvrir la Belgique !

Hibernate un ami qui vous veut du bien ?

Cet article est un retour d’expérience sur la mise en place d’une pagination dans un écran de recherche contenant un filtre composé de deux listes déroulantes. Hibernate fonctionne avec la majorité des SGBD. Toutefois, ceux-ci n’offrent pas tous les mêmes fonctionnalités. Le SQL natif généré par Hibernate sera différent selon les SGBD. Nous verrons en quoi cela peut poser problème.

Ce cas s’appuie sur une application utilisant Hibernate et Sybase ASE 12.5. L’écran à développer, en plus de la pagination, possède un filtre facultatif. La clause where étant dynamique, je décide d’utiliser les Criteria pour écrire ma requête.  Il y a dans le manuel Hibernate une section dédiée à la pagination. Elle vous conseille d’utiliser les méthodes setFirstResult et setMaxResults de l’interface Query en précisant qu’Hibernate sait comment traduire ceci en SQL natif adapté à votre SGBD.

J’implémente ma dao et je filtre le résultat renvoyé :

[[code]]czoyODI6XCJDcml0ZXJpYSBjcml0ID0gc2Vzc2lvbi5jcmVhdGVDcml0ZXJpYShGbHV4LjxzdHJvbmc+PHNwYW4gc3R5bGU9XFxcImNvbHtbJiomXX1vcjogIzgwMDA4MFxcXCI+Y2xhc3M8L3NwYW4+PC9zdHJvbmc+KTsKPHNwYW4gc3R5bGU9XFxcImNvbG9yOiAjMDA4MDAwXFxcIj4vL2Fqb3V0e1smKiZdfSBkZXMgcmVzdHJpY3Rpb25zIOKAkyBmaWx0cmUgdXRpbGlzYXRldXI8L3NwYW4+Ckxpc3QgcmVzdWx0ID0gY3JpdC5zZXRGaXJzdFJ7WyYqJl19ZXN1bHQoZmlyc3RSZXN1bHQpCiAgICAgICAgICAgIC5zZXRNYXhSZXN1bHRzKG5iUm93cykubGlzdCgpO1wiO3tbJiomXX0=[[/code]]

J’écris mon test unitaire, je réalise quelques tests sur ma base de données de test, je « commit ». Voilà, c’est fini !

Quelque temps plus tard, le chef de projet souhaite faire des tests en pré-qualification sur un nombre de lignes conséquent (il est vrai que tester la pagination quand il n’y a qu’une seule page ce n’est pas très drôle). La pagination fonctionne sur les premières pages, mais impossible d’afficher la dernière page sans faire tomber l’application. Le message d’erreur suivant est très explicite :

<10 juin 2010 15 h 20 CEST> <Critical> <Health> <BEA-310003>
<Free memory in the server is 4 122 880 bytes. There is danger of OutOfMemoryError>
[[code]]czoyODI6XCI8c3BhbiBzdHlsZT1cXFwiY29sb3I6ICNmZjAwMDBcXFwiPkV4Y2VwdGlvbiBpbiB0aHJlYWQgXFxcIltBQ1RJVkVdIEV4ZWN1dGV7WyYqJl19VGhyZWFkOiBcXFwnMThcXFwnIGZvciBxdWV1ZTogXFxcJ3dlYmxvZ2ljLmtlcm5lbC4KRGVmYXVsdCAoc2VsZi10dW5pbmcpXFxcJ1xcXCIgamF2YS57WyYqJl19bGFuZy5PdXRPZk1lbW9yeUVycm9yOiBKYXZhIGhlYXAgc3BhY2UKCi4uLgpUaGUgZXhjZXB0aW9uIG1lc3NhZ2UgaXMgLSBKYXZhIHtbJiomXX1oZWFwIHNwYWNlCmphdmEubGFuZy5PdXRPZk1lbW9yeUVycm9yOiBKYXZhIGhlYXAgc3BhY2U8L3NwYW4+XCI7e1smKiZdfQ==[[/code]]

En regardant le code SQL généré par Hibernate, on remarque qu’il n’y a pas de filtre pour la pagination. Malheureusement, Sybase possède moins de fonctionnalités que d’autres SGBD et ne connaît pas les mots clef « LIMIT » ou « ROWID » et de ce fait, le setFirstResult et setMaxResults ne sont pas traduits en SQL natif. Hibernate est donc obligé de tout récupérer dans sa requête et de faire le filtre de pagination côté java. Il charge les objets en mémoire tant qu’il n’a pas les résultats souhaités pour la page demandée. Cela ne pose pas de problème pour les premières pages, mais lorsqu’on veut atteindre la dernière page, la consommation mémoire explose.

Utilisation de la mémoire - schéma de JConsole

Figure 1 – Utilisation de la mémoire – schéma de JConsole

Ainsi, nous ne pouvons pas utiliser l’interface Query dans ce cas. Cette version de Sybase ne supporte pas non plus les sous requêtes ordonnées. La seule solution que nous avons trouvée est de faire la  requête en deux temps : d’abord sur les identifiants, puis récupérer les données  à partir de ceux-ci.

Cette solution peut s’implémenter de deux façons :

  • Solution 1 : récupérer la liste des identifiants filtrées par Hibernate (même code qu’au début, mais en ne retournant que les identifiants) ;
  • Solution 2 : obtenir la liste de tous les identifiants, puis la filtrer en utilisant la méthode subList de l’interface List.

Nous avons testé les deux solutions. En observant l’utilisation de la mémoire, la solution 2 semble plus performante.

img2-solution1

Figure 2 – utilisation de la mémoire pour la solution 1

Utilisation de la mémoire pour la solution 2

Figure 3 – utilisation de la mémoire pour la solution 2

Pour finir, on a une première requête écrite avec les Criteria qui permet de récupérer tous les identifiants en fonction des filtres de l’utilisateur. Puis, on crée une sous-liste pour ne garder que les id correspondant à la page demandée. On fait une dernière requête en HQL pour récupérer les objets.

[[code]]czo3ODI6XCJDcml0ZXJpYSBjcml0ID0gc2Vzc2lvbi5jcmVhdGVDcml0ZXJpYShGbHV4LjxzcGFuIHN0eWxlPVxcXCJjb2xvcjogIzgwMHtbJiomXX0wODBcXFwiPjxzdHJvbmc+Y2xhc3M8L3N0cm9uZz48L3NwYW4+KTsKPHNwYW4gc3R5bGU9XFxcImNvbG9yOiAjMDA4MDAwXFxcIj4vL2Fqb3V0e1smKiZdfSBkZXMgcmVzdHJpY3Rpb25zIOKAkyBmaWx0cmUgdXRpbGlzYXRldXI8L3NwYW4+CgpMaXN0IGxzSWQgPSBjcml0LnNldFByb2plY3R7WyYqJl19aW9uKAogICAgICAgICAgIFByb2plY3Rpb25zLnByb3BlcnR5KDxzcGFuIHN0eWxlPVxcXCJjb2xvcjogIzAwMDBmZlxcXCI+XFxcImlkXFxcIjwve1smKiZdfXNwYW4+KSkubGlzdCgpIDsKCkxpc3QgcmVzdWx0ID0gbnVsbDsKCmlmICggbHNJZCAhPSBudWxsICZhbXA7YW1wOyZhbXA7YW1wOyB7WyYqJl19IGxzSWQuc2l6ZSgpJmFtcDtndDswKSB7Cgk8c3BhbiBzdHlsZT1cXFwiY29sb3I6ICMwMDgwMDBcXFwiPi8vc2kgbGEgbGlzdGUgZFxcXCdpZHtbJiomXX0gZXN0IHZpZGUsIGxhIHJlcXXDqnRlIGhxbCBwbGFudGU8L3NwYW4+CglRdWVyeSBxID0gZ2V0U2Vzc2lvbkZhY3RvcnkoKS5nZXRDe1smKiZdfXVycmVudFNlc3Npb24oKS5nZXROYW1lZFF1ZXJ5KAogICAgICAJCTxzcGFuIHN0eWxlPVxcXCJjb2xvcjogIzAwMDBmZlxcXCI+XFxcImdldEx7WyYqJl19aXN0Rmx1eEJ5SWRzXFxcIjwvc3Bhbj4pLnNldFBhcmFtZXRlckxpc3QoCgkgICAgICA8c3BhbiBzdHlsZT1cXFwiY29sb3I6ICMwMDAwZmZ7WyYqJl19XFxcIj5cXFwiaWRMaXN0XFxcIjwvc3Bhbj4sCgkgICAgICBsc0lkLnN1Ykxpc3QoZmlyc3RSZXN1bHQsCgkgICAgICBsYXN0UmVzdWx0KSk7CntbJiomXX0KCXJlc3VsdCA9IChMaXN0KSBxLmxpc3QoKTsKfVwiO3tbJiomXX0=[[/code]]

A retenir :

Hibernate est votre ami, mais il ne peut pas être plus fort que votre SGBD. Il est donc utile de vérifier le code SQL natif qu’il génère.

Concernant Syabse ASE 12.5, on espère que les versions futures supporteront les fonctions liées à la pagination.

Je remercie David, Ellène et Victor pour la relecture et les conseils sur WordPress.

ParisJUG de Juin : Rencontre avec Holly Cummins (1)

Cette soirée fut drôlement riche en évènement et en surprise … Ne dévoilons pas tout et commençons par la première partie de soirée : l’AvantJUG.

L’AvantJUG

Pas mal de Duchess sont présentes, certaines accompagnées de leur collègue, et quelques nouvelles qui assistent pour la première fois à l’AvantJUG. Nicolas Martignole auteur de l’incontournable blog Le Touilleur Express a assisté à l’AvantJUG en tant qu’observateur pour voir comment se passait notre première partie de soirée.
AjantJUG-Juin

Dans les conversations, on pouvait entendre qu’il y a un iPad à gagner ce soir ! En plus des bières promis par les organisateurs du ParisJUG pour tout ce qui arrivaient les cheveux bleus, cela promet d’être une belle soirée :) . D’ailleurs en parlant de cheveux bleus, certaines d’entre nous ont profité des bombes à laques bleus amenées par Laure pour réaliser une petite séance de coiffure improvisée.

Déjà 19h ? On se prépare et en route pour l’ISEP !

Avant de commencer la soirée …

Antonio prend la parole pour faire le point sur les JUG et Oracle. Après quelques mois de silence, Oracle s’est enfin prononcé sur leurs intentions par rapport au JUG. Ils ont décidé de mettre en place 3 catégories de JUG :

  • les gros JUG avec plus de 1000 membres et un cadre juridique pour qui Oracle sortira le tapis rouge avec soutien en force,
  • les JUG de taille moyenne qu’Oracle soutiendra … moralement on va dire,
  • et les JUG virtuels qui auront droit à une petite tape dans le dos avec un “C’est sympa ce que vous faîtes”.

Le petit souci du ParisJUG, c’est que nous sommes 200 à nous réunir chaque mois et un millier sur la mailing list mais juridiquement il est composé de trois membres ! Alors comment Oracle les considèrera ?

La présentation débute maintenant …

L’optimisation des performances : pas si effrayant que ça !

IMG_0235_500Holly Cummins commence tout d’abord par nous remercier pour l’accueil en français s’il vous plaît !

Elle poursuit ensuite par une présentation de son parcours au travers de sa couleur de cheveux.

  • En 2001, les cheveux roses, elle arrive chez IBM pour travailler sur Websphere.
  • En 2004, pour se rapprocher des couleurs d’IBM, elle choisit le bleu et au même moment elle commence à travailler sur les performances de la JVM.
  • Actuellement, avec les cheveux tout simplement noir, elle contribue au projet open source Apache Aries.

Les performances ce n’est pas si terrible que ça ! Holly souhaite dédramatiser la situation.

Une application répondant mal, ce n’est pas seulement problématique mais aussi coûteux :

  • en électricité : cela consomme beaucoup surtout quand on a des data centers comme Google,
  • les employés utilisant ces applications sont moins productifs,
  • une perte de business à cause de pages qui ne répondent pas assez vite voire même pas du tout.

La loi de Moore prédit que l’on aura des processeurs de plus en plus rapides mais les SI peuvent ils se permettre de changer de matériels régulièrement pour améliorer leur performance ? Le problème c’est surtout qu’on a atteint le maximum de la scalabilité verticale. On ne peut pas faire tourner les processeurs plus vite pour une question de dissipation de chaleur. Par ailleurs, à l’heure actuelle c’est l’accès aux données en mémoire qui limite les vitesses de processeurs. On fait de la scalabilité horizontale c’est à dire qu’on augmente le nombre de core. Mais cette technique impose de réaliser des tâches en parallèle et pose donc plus de problème de synchronisation.

A son arrivée chez IBM, connaissant peu de choses sur les performances, selon ses termes, elle a cherché quelques livres pour l’aider. Et malheureusement dans la monstrueuse bibliothèque d’IBM seuls deux livres traitaient de la performance !

Méthodologie

Les performances sont limitées par les ressources. Il faut donc trouver le goulet d’étranglement et régler le problème. Un exercice qui n’est pas toujours facile à appliquer en général. Voici quelques ressources à considérer : le CPU, les accès mémoire, l’espace mémoire, les accès disques …
Il faut comprendre comment la JVM fonctionne afin de trouver le problème. Il est indispensable également de se faire aider d’outils qui fourniront des mesures et permettront de détecter ce goulet d’étranglement.

Les outils de performance d’IBM

IBM fournit un certain nombre d’outils permettant de mesurer et détecter plus facilement les goulets d’étranglement. Ils sont disponibles gratuitement sur le site IBM Assistant. Mais attention ces outils fonctionnent majoritairement sur les JVM d’IBM.

Détecter les problèmes liés à la mémoire

La mémoire est une ressource critique car elle ne peut pas être dimensionnée à l’infini. Elle est d’abord limitée par la mémoire physiquement disponible. Ensuite, il est souvent nécessaire de faire un compromis entre la quantité de mémoire et le temps que prendront les phases de Garbage Collection.
Pour identifier les problèmes de mémoire, deux types d’outils sont possibles : les traces de l’activité du GC et l’inspection du contenu de la heap (un heap dump).
Activer l’option -verbose:gc sur la JVM permet de tracer les executions du Garbage Collector et d’identifier des fréquences ou des volumes anormaux. L’outil GC and Memory Visualizer permet d’exploiter ces traces et de les représenter visuellement. Cette technique permet de voir quand la mémoire est sur-utilisé et de constater une fuite mémoire mais pas de savoir par quel type d’objets.
Pour cela il est nécessaire de réaliser un heap dump.
Pour visualiser les fuites mémoire, voici deux outils qu’elle nous conseille :

  • Health Center est un outil d’IBM permettant de réaliser le diagnostic et le monitoring des applications Java. Il permet de visualiser les classes utilisées, l’utilisation de la mémoire, les entrées/sorties …
  • Memory Analyzer (MAT)  pour visualiser les appels aux objets et la mémoire prise par ces objets.

Dans la démo, Holly nous montre un exemple d’utilisation de ces outils. Il y a un trop grand nombre de String, ainsi qu’un très grand nombre d’entrées de Map. Le souci dans cette application est que des chaînes sont générées dynamiquement pour chaque utilisation d’un label de produit.

La mémoire native

On appelle mémoire native la mémoire utilisée par le core de la JVM pour gérer les processus natifs de la JVM (gestion des threads, gestion de la mémoire, gestion de la pile d’appel). Cette mémoire est distincte de la Heap qui est la zone dans laquelle les objets manipulés par les applications sont créés. Il arrive que les fuites se produisent dans la mémoire native parce qu’elles sont causées par des processus natifs de la JVM. Or cette mémoire n’est pas traitée par les outils dont on vient de parler. Il faut utiliser les outils de l’OS perfmon sous Windows et ps sous Linux pour surveiller la mémoire totale du process JVM pour identifier une dérive.

Détecter les problèmes liés au CPU

Tout d’abord, les problèmes de CPU sont souvent en réalité des problèmes de mémoire. Le GC cause beaucoup d’opérations sans entrées sorties et donc génère souvent de fortes consommations CPU. Les problèmes liés au CPU sont en général du code invoqué plus que nécessaire. Pour détecter ces problèmes, deux méthodes existent :

  • méthode de tracing : pour savoir dans quels méthodes passent notre application et trouver la méthode nous posant problème,
  • méthode de profiling : pour cela, il nous faut un outil de profiling comme Health Center par exemple.

Paradoxalement, une utilisation très basse de la CPU peut indiquer également un problème parce que dans ce cas ce sont des attentes qui dégradent les temps de réponse. Le système qui attend des entrées/sorties ne consomme pas de CPU.

Détecter les problèmes liés aux entrées/sorties

Il existe deux causes de problèmes d’entrées/sorties : les accès disque et les appels réseau.
Les accès disques peuvent ralentir le service si le disque n’arrive pas à traiter les demandes suffisamment vite. Cela peut arriver pour une application fortement consommatrice d’écriture (via les logs par exemple). Mais la gestion des swaps mémoire peut également causer une sur-utilisation des disques pour des process s’allouant de grandes quantités de mémoire.
L’autre source de dégradation par entrées/sorties est causée par les requêtes aux SGBD ou avec des services en backend.
Le problème n’est pas évident à détecter. Il faut utiliser les outils du système en conjonction avec les outils de profiling pour enquêter et trouver le problème.

Synchronization : la concurrence et la performance

Holly avoue que les problèmes d’accès concurrents ne sont pas faciles à résoudre. La nécessité de conserver la cohérence entre les actions des différents threads impose d’utiliser une forme de verrou (les synchronized) qui limitent les performances sous forte concurrence. Il faut donc les réduire au maximum.

L’évolution des processeurs ces derniers temps se fait par scalabilité horizontale et implique que l’on ne peut plus gagner en performance simplement en ayant des processeurs qui vont plus vite. Pour utiliser au mieux les multi-cores, il faut savoir paralléliser les tâches, ce qui nécessite de trouver un bon compromis entre synchronisation des données et augmentation du débit.

Fin de la première partie, nous passons au buffet.

Le buffet

Buffet
Mais avant une petite photo groupée autour de Holly Cummins de tout ce qui ont eu le courage de venir les cheveux colorés. Le buffet fut sponsorisé par Octo. Pour cette soirée des représentants du BreizhJUG, NormandyJUG et le BruJUG sont présents.

 

Paris JUG : les performances et OSGi avec Holly Cummins

Ce mois-ci performances et OSGi sont au menu de la soirée du ParisJUG. Avec Holly Cummins notre speaker du mois, venez découvrir les deux thèmes qu’elle abordera ce soir :

Optimisation de performances

Mémoire, threads ? Tous ces concepts paraissent très mystérieux. En fait ce sont des comportements très simples dès lors qu’ils sont expliqués et aussi quand on peut les visualiser. Les outils fournis avec la Java 5 ainsi que des outils plus spécifiques permettent de visualiser les différentes zones de la mémoire, les données liées à chaque exécution du GC, le code en cours d’exécution pour chaque thread. Ces outils aident à comprendre comment une application sollicite les différentes zones de la mémoire. Certains OutOfMemory sont réfractaires aux modifications de -Xms -Xmx les paramètres qui dimensionnent la heap. C’est simplement parce que la heap ne concerne que les objets crées par l’application. D’autres zones mémoire sont utilisées pour stocker les classes, la pile d’appel. Même la heap est composée de plusieurs zones dans une JVM générationnelle.
Beaucoup de consommation CPU, l’application pause tout le temps car la JMV passe beaucoup de temps dans des GC ? L’analyse détaillée des données de GC permet de comprendre pourquoi des GC sont fréquents, quelle est la durée de vie des objets impliqués et d’avoir de premières pistes pour identifier  une consommation mémoire excessive ou s’adapter à un usage particulier.Ou alors, les réponses sont parfois lentes sans raison apparente. Ces outils aident à identifier si un thread est en train d’en bloquer un autre parce qu’ils nécessitent tous les deux l’accès à une variable protégé par un synchronized. Même si la JVM nous décharge de la gestion des allocations/dé-allocations mémoire et du multi-threading, il est utile de comprendre comment ces mécanismes marchent pour les utiliser de manière efficace en Java.

OSGi

On parle de la spécification OSGi mais savez vous de quoi il s’agit ? OSGi est une spécification ayant pour but de définir des applications modulaires, portables et dynamiques. Pour faire simple cela permet de réaliser des installations de modules à chaud sans redémarrage de la JVM. Le plus bel exemple que l’on a sans doute tous sous les yeux est Eclipse et son système de plugins par exemple qui respecte la spécification OSGi. Elle existe donc depuis un moment déjà mais revient au goût du jour pour tenter de répondre à nos problèmes de modularité sur nos applications web. Une présentation d’OSGi a été réalisée au ParisJUG en Octobre 2008 par Cyrille Leclerc et Nicolas Griso pour présenter ce que OSGi pouvait nous apporter. Depuis plus d’un an s’est écoulé, Holly Cummins va nous présenter au travers du projet open source sur lequel elle travaille Apache Aries, les enjeux d’un tel outil. Injection de dépendances, transaction et persistance : venez découvrir comment l’on peut répondre à ces problématiques avec OSGi.

En continuant à utiliser le site, vous acceptez l’utilisation des cookies. Plus d’informations

Les paramètres des cookies sur ce site sont définis sur « accepter les cookies » pour vous offrir la meilleure expérience de navigation possible. Si vous continuez à utiliser ce site sans changer vos paramètres de cookies ou si vous cliquez sur "Accepter" ci-dessous, vous consentez à cela.

Fermer