Posts Tagged 'terracotta'

TerraCotta, JPA et virtualisation

Ari Zilka, de Terracotta, a choisi d’insister sur le fait qu’une application utilisant les mécanismes de Network Attach Memory engendre les mêmes difficultés qu’une application à développer en multi-threadé. Pour cela, il s’est servi du plugin eclipse de visualisation de comportement d’un cluster Terracotta, qui permet de facilement identifier les baisses de capacité de traitement associées à l’apparition de plusieurs JVM attaquant le même contenu mémoire. Très visuel, et qui a le mérite de nous forcer à repenser la structure de nos traitements.

La session suivante a vu un présentateur Sun et un présentateur Oracle parler d’un projet… Eclipse : la nouvelle version de l’implémentation JPA TopLink, à savoir EclipseLink. Cette version sera complète et open source, en contenant tout ce qu’il y avait dans Toplink et pas seulement la partie JPA. Elle sera embarquée dans le serveur d’application Glassfish V3. Après un rappel des principes de JPA, on a passé en revue un certain nombre de spécificités TopLink : principalement orientées optimisation, comme le weaving, optimisation optionnelle du bytecode en fonction d’un certains nombres de paramètres, ou la gestion avancée du cache et de tout ce qui peut éviter les problèmes de n+1. Enfin, un annonce qui fera plaisir à certains, l’introduction d’un lock pessimiste, le tout pour juillet 2008. Bon, ça c’était en gros du Oracle, mais que venait faire le Sun guy là dedans ? Et bien il venait justement nous rassurer ("c’est Eclipse, mais on travaille tous ensemble, etc.") et surtout nous parler de l’intégration dans NetBeans 6.1. Il faut avouer que c’est bien abouti, avec des assistants intelligents, de la config automatique en fonction du serveur d’application, et l’import à partir de la base de données pour donner des classes entités directes. Pour ceux qui ont un peu fait l’impasse sur NetBeans depuis un petit bout de temps ("chez nous on a que du Eclipse/RAD", "c’est du Swing donc ça rame", etc.), je vous invite à profiter de la sortie en début de semaine de la version 6.1 pour ré-évaluer cet IDE, qui peut vous surprendre : ça tourne bien, je peux créer mes JSF facilement, JPA est d’office, et en bonus j’ai UML et BPEL.

Pour finir, une session AMD sur les impacts méconnus de la virtualisation (avec hyperviseur et VMWare ESX) sur nos JVM de serveurs d’application : en effet, en dehors de l’estimation classique d’overhead de 10%, il y a des zone moins faciles au premier abord. En effet, il faut savoir qu’au delà de 986 Mo alloués pour un Linux, la façon de gérer la mémoire de la VM par l’hyperviseur change et peu avoir un impact fort. Bien sur, les I/O disques et réseaux sont à prendre en compte, en déportant sur le SAN pour les premiers et en allouant une carte physique séparée pour chaque VM. Sans oublier l’influence du paramétrage du GC pour qu’il prenne en compte correctement les différents CPU. Rien que des recommandations de bon sens, mais que l’on peut parfois oublier. AMD offre bien sur des techniques pour aider notamment au paging mémoire.

Clustering: du nouveau avec TerraCotta

Le terme clustering regroupe un ensemble de techniques destinées à améliorer les performances des applications en agissant sur la disponibilité et la capacité de montée en charge. Dans la pratique, cela consiste à installer l’application cible sur plusieurs serveurs physiques, et, à les présenter comme un seul serveur logique en utilisant des solutions telles que le load-balacing ou le session fail-over.

Dans le monde Java, le clustering n’est proposé que sur les versions avancées des serveurs d’application. Il est d’ailleurs intéressant de noter que ces solutions sont propriétaires et qu’elles ne sont pas standardisées au niveau de la norme J2EE. Par ailleurs, elles sont assez complexes à mettre en oeuvre.

La société TerraCotta propose quant à elle une solution originale basée sur le clustering au niveau de la JVM. Le principe est simple et repose sur un mécanisme de mémoire partagée qui permet l’utilisation simultanée d’instances d’objets Java dans plusieurs JVM situées sur des machines distinctes.

Les objets partagés sont gérés par un serveur qui fonctionne à l’intérieur de sa propre JVM et qui sauvegarde l’état des objets distribués sur disque. Cette technique permet de mettre le serveur TerraCotta lui-même en cluster (de type actif/passif) pour éviter de constituer un single point of failure (SPOF).

Du côté des applications clientes, il suffit d’embarquer la bibliothèque cliente TerraCotta et d’ajouter des paramètres  dans la ligne de commande du programme. Ainsi, l’impact de cette solution sur la conception d’une application est quasiment nulle. A noter que les objets Java partagés ne sont pas contraint d’implémenter une quelconque interface (même Serializable) ou d’hériter d’une classe de la bibliothèque TerraCotta.

TerraCotta existe en 3 éditions différentes :

  • TerraCotta DSO offre le partage en réseau des objets Java classiques (les POJO),
  • TerraCotta Sessions simplifie la mise en cluster des applications J2EE en déléguant à TerraCotta la gestion des sessions HTTP,
  • TerraCotta for Spring permet l’utilisation d’objets partagés avec le framework Spring.

Enfin, en plus de ses qualités techniques remarquables, TerraCotta vient de passer sur un modèle 100 % Open Source, complété par la distribution (payante) d’une édition certifiée comprenant le support technique.

Avec des atouts pareils, TerraCotta devrait connaître un succès rapide. 

Vous trouverez plus d’informations sur les liens suivants:


Mises à jour Twitter

Entrer votre adresse e-mail pour vous inscrire a ce blog et recevoir les notifications des nouveaux articles par e-mail.

Rejoignez 29 autres abonnés

Catégories

Statistiques

  • 64,079 hits