|
Stratégies pour la gestion du cache dans une architecture MVC
Parce qu’il est
récipiendaire de toutes les requêtes entrantes vers l’application, le contrôleur
de l'architecture MVC est un très bon emplacement pour implémenter la gestion du
cache. Sa position intermédiaire dans l’architecture lui permet de
connaître les objets fréquemment utilisés par les clients et le caractère plus
ou moins volatile de leurs états. Le rôle d’un bon contrôleur ne se limite pas à
l’identification des objets pouvant être mis en cache. Il lui revient également
de mettre en œuvre une stratégie efficace pour rafraîchir, alimenter et libérer
la mémoire cache de manière à :
• Eviter les fuites de mémoire (memory leaks) [170].
• Limiter la génération dynamique des pages.
• Limiter les accès à la base de données.
Les stratégies conventionnelles de rafraîchissement du cache reposent sur
l’échange de messages synchrones entre le contrôleur et la source des données
mises en cache. Dans ce modèle le contrôleur envoie périodiquement des messages
à la source pour vérifier que les objets mis en cache n’ont pas changé d’état.
Vu que les messages envoyés sont synchrones le contrôleur reste en instance
jusqu'à ce que la source lui réponde. A moins de ne lui attribuer un processus
dédié cette opération peut bloquer le contrôleur et condamner le fonctionnement
total de l’application. L’opération épuise aussi la source qui doit sacrifier
une partie de ses ressources [171] pour répondre au contrôleur même si les objets mis
en cache n’ont pas changé d’état.
Pour de meilleures performances, c’est la source qui doit avertir la destination
lorsque l’état des objets change. L’inversion du sens de la communication
soulage, en effet, le réseau et diminue les risques de blocage au niveau du
contrôleur. Malheureusement ce mode de
communication inversé n’est pas
supporté par les browsers au niveau de la couche de présentation. Cependant, au niveau de la couche de contrôle il y a
techniquement plusieurs possibilités.
L’avènement de l’API JMS et des messages driven beans a solidifié le rôle joué
par les messages asynchrones dans la gestion du cache. Grâce à ces messages le
contrôleur est exempté d’une partie de sa charge de travail et jouie d’un
meilleur taux de disponibilité. Un peu comme dans un serveur de nouvelles le
contrôleur s’inscrit auprès d’un message driven bean ou d’un serveur de messages
JMS qui doivent le notifier à chaque fois que l’état des objets mis en cache
change (subscribe/publish). Dès réception de cette notification le contrôleur
met à jour les données conservées dans le cache de façon à refléter les
changements d’états récemment survenus (cf. figure 35).
Figure 35: Rôle joué par les messages asynchrones dans la gestion du cache
[172]
Dans les applications
J2EE la stratégie de gestion de cache est souvent codée à l’intérieur des
filtres (servlet filters) qui comme nous l’avons vu dans cet
article
interceptent toutes les requêtes /réponses en amont/aval du contrôleur/ de la
vue. En amont les requêtes portant sur des données déjà mises en cache sont
interceptées par le(s) filtre(s) qui les empêche(nt) d’arriver jusqu’au
contrôleur (servlet). De cette façon ces requêtes reçoivent des réponses plus
rapidement. Les requêtes destinées aux données non placées dans le cache sont
relayées vers le contrôleur mais en aval les réponses y afférentes sont à leur
tour mises en cache comme le montre la figure 36.
NB : le cas échéant, le filtre qui gère le cache doit être placé après
celui qui gère la sécurité pour empêcher des personnes non autorisées d’accéder
à des données confidentielles.
Figure 36: Gestion de cache au moyen d’un Servlet Filter
[173]
Les objets sont mis en
cache dans la mémoire vive du serveur, sur son disque dur ou encore dans la
mémoire cache du browser. Chacun de ces récipients présente les avantages et les
inconvénients énumérés ci-dessous :
*
Mémoire vive du serveur : ce récipient est rapide d’accès mais il ne permet de
stocker qu’une quantité limitée de données. Pour que cette mémoire soit gérée
rationnellement il faut utiliser des algorithmes qui éliminent (flush)
rapidement les données superflues et qui mettent en cache celles ayant une très
forte probabilité d’être demandées par les prochaines requêtes [174]. Parmi ces
algorithmes on peut citer :
• Least Frequently Used (LFU): comme son nom l’indique cet algorithme élimine du
cache les données non récemment demandées. Dans les programmes il est mis en
œuvre par le biais d’une liste qui place au premier rang toute donnée
nouvellement demandée. Au fur et à mesure de l’arrivée des requêtes, les données
les moins demandées sont surclassées jusqu'à ce qu’elles soient définitivement
éliminées de la liste.
• First In, First Out (FIFO): très rarement utilisé cet algorithme élimine du
cache l’élément le plus ancien de la liste (premier entré, premier sorti).
• Last in, First Out (LIFO) : la dernière donnée ajoutée au cache est éliminée
en premier.
NB : cette liste n’est pas limitative. Pour connaître les autres algorithmes
nous recommandons la lecture des deux livres suivants :
√ Duane Wessels, Web Caching, O'Reilly, First Edition June 2001, ISBN:
1-56592-536-X, pages 318
√ Michael Rabinovich and Oliver Spatscheck, Web Caching and Replication, Addison
Wesley, December 21, 2001, 0-201-61570-3, pages 400
*
Disque dur du serveur: ce récipient permet de stocker plus de données que la
mémoire vive mais cela se fait au détriment du temps de réponse.
*
Mémoire cache du browser : comparé aux autres, ce récipient offre une bonne
capacité de stockage et le meilleur temps de réponse mais il présente aussi des
inconvénients que nous avons décrits dans cet
article.
Remarque 1 : pour connaître les objets qui peuvent être mis
en cache dans une application de commerce électronique, consulter les articles
suivants:
Besoins en performance des sites B2C.
Besoins en performance des sites B2B.
Besoins en performance des sites C2C.
Remarque 2:
les données peuvent être également mises en cache dans d’autres récipients comme
les conteneurs, les routeurs ou encore les serveurs proxy.
Notes de bas de page
[170] Contrairement à
une croyance largement répandue le garbage collector ne prévient pas toujours
les fuites de mémoire.
[171] Mémoire, processeur, temps de réponse …
[172] Adaptation d’un digramme de séquence publié dans J2EE Design Patterns,
William Crawford, Jonathan Kaplan, O'Reilly, September 2003, ISBN:
0-596-00427-3, pages 368
[173] Adaptation d’un digramme de séquence publié dans J2EE Design Patterns,
William Crawford, Jonathan Kaplan, O'Reilly, September 2003, ISBN:
0-596-00427-3, pages 368
[174] Par exemple les données relatives aux produits vedettes.
|
Accueil 
Optimisation 
