The new ehcache 2.0 and hibernate spi
View more presentations from Cyril Lakech.
mardi 20 juillet 2010
samedi 17 juillet 2010
Compte-rendu Soirée Ehcache / Terracotta @ ZenikaIT
J'ai eu la chance de pouvoir assister chez Zenika à une conférence animée par Greg Luck, qui est le créateur d'Ehcache et qui travaille maintenant chez Terracottech, la société qui développe Terracotta, une solution de cache distribuée.
Sa présentation se décompose en 3 parties, les intérêts de l'utilisation du cache, les nouveautés dans Ehcache 2 et les performances d'Ehcache.
Alors pourquoi utiliser du cache ? Pour le fun, parce que c'est à la mode ?
1/ Pour réduire la consommation de ressources
2/ Pour améliorer les performances
3/ Pour scaler en distribuant les données avec le cache
Pour cela c'est très simple, il suffit de raccourcir le parcours et le traitement de la demande d'informations. Vous avez un service qui doit aller charger des données en base, et bien la première fois vous allez effectivement charger ces données depuis la base de données mais les fois suivantes, pas besoin d'aller jusqu'à la base de données car vous avez pris soin de garder cette donnée au plus près de là ou vous en avez besoin. Donc vous raccourcissez le traitement entre la requête et la réponse.
Ensuite, il nous explique la loi d'Amdhal qui aide a comprendre comment on peut accélérer un système en s'attaquant au composant du système qui est le mieux placé pour être amélioré. Bref, voyez avec M. Wikipedia, il expliquera cela très bien.
Après quoi, on comprend comment l'efficacité du cache est calculée, c'est le rapport entre les requêtes du cache sur les requêtes totales. Une grande efficacité est égale à un grand offload et a de grandes performances.
Pourquoi le cache fonctionne t-il ?
Parce qu'il rapproche les données demandées au plus près du besoin.
La distribution de pareto est ensuite expliquée, il faut mettre en cache les parties du système qui sont le plus demandées et pas la totalité.
Ensuite, il nous explique pourquoi il faut utiliser un cluster; pour la disponibilité et pouvoir scale out (et non scale up)
Mais cela entraine d'autres problèmes :
- cela ajoute aurant de problèmes qu'il y a de nœuds car ils doivent récupérer l'information,
- la cohérence du cluster quand l'information se trouve à plusieurs endroits,
- la limite du théorème de CAP, qu'il renomme en PACELC :
« if there is a partition (P) how does the system tradeoff between availability and consistency (A and C); else (E) when the system is running as normal in the absence of partitions, how does the system tradeoff between latency (L) and consistency (C)? »
Et il n'y a pas de bonne réponse, car cela dépend de chaque application, il faudra donc que la solution soit configurable.
http://dbmsmusings.blogspot.com/2010/04/problems-with-cap-and-yahoos-little.html
Parlons un peu d'Ehache !
Il nous a dresser un beau tableau d'Ehcache, un solution robuste, qui tien la route, répandue, open source etc etc... Bref, LA solution de cache qu'il vous faut !
Il compare ensuite Ehcache avant et après le passage de Terracotta, en sommes c'est comme dans les pubs avant/après pour les rasoirs à 15 lames sauf que la ca vaut vraiment le coup de voir l'évolution !
Puis on regarde les modifications à apporter à ehcache pour mettre en place Terracotta: il suffit d'ajouter 3 lignes au ehcache.xml, vraiment très simple.
Les nouveautés de Ehcache 2:
-Compatibilité avec Hibernate 3.3+, refonte du SPI, union avec Terracotta 3.2,
-JTA compliant (avec XA, spring, ejb, config manuelle etc),
-Write-Behing: l'écriture dans le cache en tache de fond (asynchrone)
-Nouveaux paramètres de tuning
-Du monitoring (avec JMX) dans une nouvelle UI
-Et la ehcache console (dans la version 2.1)
Waou... une vrai version majeure, il y a tellement de nouvelles choses qu'il faudrait une heure pour expliquer chaque partie.
On a ensuite des démo de la Terracotta console et de la Ehcache console, impressive !
Après quoi on a tout un tas de comparaison des performances des solutions Terracotta/Ehcache versus le reste du monde : IMDG, memcached, mysql (pour l'exemple d'une BDD en directe)
On retrouve les sources de ces bench en ligne: https://svn.terracotta.org/repo/forge/projects/ehcacheperf/ (compte svn = identifiants de terracotta.org)
En conclusion, la mise en place de Ehcache avec Terracotta sur la fameuse application PetClinic nous donne:
-de 30 à 95% de réduction du chargement de la BDD
-des performance 80 fois supérieures à mysql
-beaucoup moins de temps de latence évidemment
Parlons du NoSql dans tout ca, et bien en fait, la combinaison Ehcache/Terracotta est une solution de NoSql sans capacité de recherche (humhum... moyen l'argument) mais par contre, il projet voit le jour, TerraStore, un "document oriented NoSQL store based on Terracotta" La classe !
www.ehcache.org
www.terracottatech.com
C'est la fin, où plutôt l'heure des Goodies a gagner par programme random SVP: un iPod & 2 places pour un conférence IT @ SF (javaone). Et je n'ai rien gagné, flute, par contre j'ai pas mal appris sur ce beau sujet qui à un bel avenir, et pour ca, je dis merci Zenika pour l'organisation de cette session et merci ADEO de m'avoir laissé m'y rendre.
A la question, "Est-ce que les slides seront mis à dispo en ligne?" la réponse de Greg a été : "No problem, OK". Alors si vous voulez les slides... demandez moi ;-)
J'ai eu la chance de pouvoir assister chez Zenika à une conférence animée par Greg Luck, qui est le créateur d'Ehcache et qui travaille maintenant chez Terracottech, la société qui développe Terracotta, une solution de cache distribuée.
Sa présentation se décompose en 3 parties, les intérêts de l'utilisation du cache, les nouveautés dans Ehcache 2 et les performances d'Ehcache.
Alors pourquoi utiliser du cache ? Pour le fun, parce que c'est à la mode ?
1/ Pour réduire la consommation de ressources
2/ Pour améliorer les performances
3/ Pour scaler en distribuant les données avec le cache
Pour cela c'est très simple, il suffit de raccourcir le parcours et le traitement de la demande d'informations. Vous avez un service qui doit aller charger des données en base, et bien la première fois vous allez effectivement charger ces données depuis la base de données mais les fois suivantes, pas besoin d'aller jusqu'à la base de données car vous avez pris soin de garder cette donnée au plus près de là ou vous en avez besoin. Donc vous raccourcissez le traitement entre la requête et la réponse.
Ensuite, il nous explique la loi d'Amdhal qui aide a comprendre comment on peut accélérer un système en s'attaquant au composant du système qui est le mieux placé pour être amélioré. Bref, voyez avec M. Wikipedia, il expliquera cela très bien.
Après quoi, on comprend comment l'efficacité du cache est calculée, c'est le rapport entre les requêtes du cache sur les requêtes totales. Une grande efficacité est égale à un grand offload et a de grandes performances.
Pourquoi le cache fonctionne t-il ?
Parce qu'il rapproche les données demandées au plus près du besoin.
La distribution de pareto est ensuite expliquée, il faut mettre en cache les parties du système qui sont le plus demandées et pas la totalité.
Ensuite, il nous explique pourquoi il faut utiliser un cluster; pour la disponibilité et pouvoir scale out (et non scale up)
Mais cela entraine d'autres problèmes :
- cela ajoute aurant de problèmes qu'il y a de nœuds car ils doivent récupérer l'information,
- la cohérence du cluster quand l'information se trouve à plusieurs endroits,
- la limite du théorème de CAP, qu'il renomme en PACELC :
« if there is a partition (P) how does the system tradeoff between availability and consistency (A and C); else (E) when the system is running as normal in the absence of partitions, how does the system tradeoff between latency (L) and consistency (C)? »
Et il n'y a pas de bonne réponse, car cela dépend de chaque application, il faudra donc que la solution soit configurable.
http://dbmsmusings.blogspot.com/2010/04/problems-with-cap-and-yahoos-little.html
Parlons un peu d'Ehache !
Il nous a dresser un beau tableau d'Ehcache, un solution robuste, qui tien la route, répandue, open source etc etc... Bref, LA solution de cache qu'il vous faut !
Il compare ensuite Ehcache avant et après le passage de Terracotta, en sommes c'est comme dans les pubs avant/après pour les rasoirs à 15 lames sauf que la ca vaut vraiment le coup de voir l'évolution !
Puis on regarde les modifications à apporter à ehcache pour mettre en place Terracotta: il suffit d'ajouter 3 lignes au ehcache.xml, vraiment très simple.
Les nouveautés de Ehcache 2:
-Compatibilité avec Hibernate 3.3+, refonte du SPI, union avec Terracotta 3.2,
-JTA compliant (avec XA, spring, ejb, config manuelle etc),
-Write-Behing: l'écriture dans le cache en tache de fond (asynchrone)
-Nouveaux paramètres de tuning
-Du monitoring (avec JMX) dans une nouvelle UI
-Et la ehcache console (dans la version 2.1)
Waou... une vrai version majeure, il y a tellement de nouvelles choses qu'il faudrait une heure pour expliquer chaque partie.
On a ensuite des démo de la Terracotta console et de la Ehcache console, impressive !
Après quoi on a tout un tas de comparaison des performances des solutions Terracotta/Ehcache versus le reste du monde : IMDG, memcached, mysql (pour l'exemple d'une BDD en directe)
On retrouve les sources de ces bench en ligne: https://svn.terracotta.org/repo/forge/projects/ehcacheperf/ (compte svn = identifiants de terracotta.org)
En conclusion, la mise en place de Ehcache avec Terracotta sur la fameuse application PetClinic nous donne:
-de 30 à 95% de réduction du chargement de la BDD
-des performance 80 fois supérieures à mysql
-beaucoup moins de temps de latence évidemment
Parlons du NoSql dans tout ca, et bien en fait, la combinaison Ehcache/Terracotta est une solution de NoSql sans capacité de recherche (humhum... moyen l'argument) mais par contre, il projet voit le jour, TerraStore, un "document oriented NoSQL store based on Terracotta" La classe !
www.ehcache.org
www.terracottatech.com
C'est la fin, où plutôt l'heure des Goodies a gagner par programme random SVP: un iPod & 2 places pour un conférence IT @ SF (javaone). Et je n'ai rien gagné, flute, par contre j'ai pas mal appris sur ce beau sujet qui à un bel avenir, et pour ca, je dis merci Zenika pour l'organisation de cette session et merci ADEO de m'avoir laissé m'y rendre.
A la question, "Est-ce que les slides seront mis à dispo en ligne?" la réponse de Greg a été : "No problem, OK". Alors si vous voulez les slides... demandez moi ;-)
Inscription à :
Articles (Atom)