NHibernate et cache de second niveau
Par Jean-Baptiste le lundi 17 mars 2008, 16:47 - Code - Lien permanent
Voilà un petit moment que j'ai pas eu l'occasion d'écrire un peu ici. Ce n'est pas qu'il ne se passe rien, c'est que mon temps est un un peu accaparé par pas mal de projets dont j'espère bientôt pouvoir parler ici.
En attendant, histoire d'alimenter ce blog avec quelque chose de léger, je vais me permettre de répéter ici ce qu'on entend un peu partout: le cache de second niveau de NHibernate est un pur bonheur.
Bon cela mérite un petit développement tout de même. Commençons par une petite définition (même s'il est possible d'en trouver un peu partout sur le net).
NHibernate est doté de deux "niveaux" de cache:
- Le cache de session, qui correspond en fait au unit of work tel que défini dans POEAA [1]. C'est ici donc que la session va garder une trace de toutes les entités qu'on lui demande.
- Le cache de la SessionFactory , dont la durée de vie et la portée est donc celle de la fabrique. Nous parlons alors de cache de second niveau par opposition au cache de la session qui est alors appelée cache de premier niveau.
L'intérêt du cache de second niveau est donc justement de permettre à l'intégralité des sessions créées par une SessionFactory de partager certaines informations. Si jamais dans notre application nous n'avons besoin que d'une seule session, alors ce cache ne sera pas très utile; mais dans le cadre d'une application web, utilisant le modèle "session-per-request" (une session par requête) nous allons avoir un très grand nombre de session. Le fait mettre en cache certaines requêtes et entités qui sont très souvent appelées représente un gain de performance assez incroyable, et pourtant je dois avouer que je n'ai pas trouvé tant de littérature que ça sur le sujet.
Pour donner un exemple concret, sur une application sur laquelle je travaille, nous avions remarqué que nous émettions entre 3 et 10 select de base par page (pour aller cherches les informations utilisateurs, des préférences, des filtres de recherche). En activant le cache de second niveau, et en analysant un peu ce qu'il fallait mettre ou non en cache, nous avons fait disparaitre ces select incompréssibles exécutés énormément de fois pour donner les mêmes résultats. Les gains sur les performances globales de l'application ont été assez conséquents, pour finalement bien peu d'investissement.
Bref, parmi tous les moyens d'optimiser les performances de nhibernate, le cache de second niveau, vu qu'il n'est pas activé par défaut, est je trouve un peu un grand oublié, alors que n'importe quelle application web peut en tirer d'énormes avantages.



Commentaires
your artical looks like food taste so delicious, much information is very useful to me. thanks