Les 10 commandements du cache

Avec un cache vous pouvez sauver la vie de votre application. Bien sûr il est déjà utile de penser à exploiter tous les caches disponibles. Pour un serveur web, par exemple, tirez parti du navigateur de vos clients. Ce cache est gratuit, ne nécessite aucune installation particulière de votre part et améliore grandement le temps de chargement ressenti par l’utilisateur. Vous pouvez aussi utiliser un CDN pour délivrer vos ressources statiques. Sur votre exploitation, vous utilisez peut-être déjà un proxy-cache (Varnish, Apache, Nginx, BlueCoat, …), un cache distant (Memcached, Redis, Gemfire, …) et sûrement un cache local allant de la simple Map à un EHCache en passant par un cache Guava. Dans notre éco-système, il est rare de trouver des applications n’utilisant pas de cache. Mais attention, un cache apparemment efficace peut s’avérer dangereux à moyen ou long terme: blocage de l’application, OutOfMemory et autres joyeusetés sont monnaie courante.
Voici donc 10 commandements pour garantir bonne utilisation, et bon fonctionnement, des caches. Ces règles sont à prendre comme une ligne de conduite qui vous permettra de ne pas vous perdre en chemin.

1 – La donnée, tu perdras !

Les données poussées dans le cache sont réputées volatiles, le simple fait de perdre une donnée du cache ne doit en aucun cas bloquer le système. Une application utilisant un cache doit clairement prendre en compte cette règle. Si vous ne pouvez pas perdre la donnée, alors ce n’est probablement pas d’un cache dont vous avez besoin. 

2 – La durée de vie, tu définiras !

Il est toujours bon de le rappeler : dans un cache les ressources ont une durée de vie. Qu’elle soit longue ou courte, qu’il s’agisse d’un Time To Live ou d’un Time To Idle, les données d’un cache finissent toujours par expirer. C’est une bonne chose, cela permet de rafraîchir régulièrement la donnée que l’on va utiliser. Pensez donc à bien choisir la stratégie d’expiration et bien sûr à déterminer finement le délai d’expiration.

3 – Le cache, tu dimensionneras !

Un cache n’est pas un puits sans fond, ne vous laissez pas flouer par l’apparente bonhomie d’un middleware de cache ou de votre cache local. Posez vous les questions: Quelle est la taille mémoire de la ressource ? Quelle quantité je veux stocker en cache ? Un cache mal dimensionné perdra tout son intérêt. Préférez un cache local si vous savez qu’il peut résider en mémoire vive dans la JVM, dans le cas contraire c’est un cache distant du type de Memcached qui sera le mieux adapté.  

4 – Le cache, tout seul, se rafraîchira !

Comme vous avez pu le voir dans les commandements précédents, la donnée est appelée à disparaître du cache. La bonne pratique est donc de prévoir un rechargement automatique de la donnée. Pensez donc à recharger la donnée, si elle a disparu. De façon générale, vous devez toujours être capable de retrouver ou régénérer la donnée. Aucune opération manuelle ne doit être nécessaire pour maintenir des données fraîches dans le cache. Trop souvent, on retrouve chez le client des applications dont les caches ne se mettent à jour qu’au démarrage.

5 – A tout instant purger, tu pourras !

Que vous utilisiez un proxy cache, un cache local ou distant, vous devez toujours disposer d’une méthode permettant de vider intégralement le cache. Cette règle est surtout importante si votre cache est un middleware qui va contenir de grosses quantités de données. Attention, si le délai de rafraîchissement des ressources est suffisamment court la purge peut s’avérer inutile.

6 – Tu utiliseras la donnée pour tous !

Les données stockées dans un cache doivent pouvoir servir à tous. Lors de la conception de votre cache prenez le temps de réfléchir à ce point. Les caches par utilisateur sont à proscrire. Tous les utilisateurs doivent pouvoir bénéficier de votre cache, qu’il s’agisse de contenu éditorial, ou de données changeant peu, sélectionnez les données éligibles finement.

7 – Le cache, tu ignoreras !

Le cache doit être discret, le développeur doit le voir le moins possible. Idéalement son utilisation doit être transparente pour le développement. Evitez de construire vos solutions autour du cache, votre solution doit pouvoir fonctionner sans cache. Si il est bon d’utiliser un cache, il est essentiel de concevoir les solutions sans cache. Le cache viendra par la suite compléter l’architecture pour améliorer les performances.

8 – Les niveaux de cache, tu multiplieras !

Vous le savez sans doute déjà, Hibernate a deux niveaux de cache, alors pourquoi pas vous ? N’oubliez pas pour les applications web que vous devez toujours bénéficier du cache du navigateur. Ajoutez un proxy cache et/ou un CDN pour vos ressources statiques ou évoluant peu (timeout faible).  A l’intérieur même de votre application, différents niveaux de cache applicatif peuvent coexister sans mal. Attention tout de même, la politique d’éviction pourra vous causer des soucis, pensez donc à mettre en place dans ce cas un timeout allant croissant de votre serveur d’application à vos utilisateurs. La mise à jour des caches applicatifs doit toujours pouvoir impacter les couches de plus haut niveaux.

9 – Les ressources de ton serveur, tu économiseras !

Si la mise en place du cache n’apporte aucune amélioration à la consommation CPU ou I/O de votre serveur, il y a fort à parier qu’il ne sert à rien. Un cache bien utilisé va vous permettre de limiter le nombre de requêtes faites au serveur (cache du navigateur, CDN, proxy), ou de réduire la charge pour générer la réponse (cache applicatif local ou distant). Le cache permettra enfin de limiter vos appels à un service ou une base de données en y stockant le résultat des appels.

10 – Le chargement de ton cache, tu protégeras !

Faites très attention au chargement de votre cache. D’une part le chargement est un processus potentiellement long et coûteux, d’autre part, le risque de charger plusieurs fois la même donnée est important. Par exemple si vous rechargez la donnée dans le cache à la demande, plusieurs requêtes en parallèle sur votre serveur pourront causer le rechargement multiple de la donnée. La bonne pratique est d’utiliser la ressource expirée pendant le chargement d’une nouvelle version. L’utilisation d’un CacheLoader Guava répond très bien à cette problématique. Pensez aussi à la montée en charge de votre cache, les middleware vous permettront de scripter le peuplement du cache avant l’ouverture de la production.

Conclusion

Comme dans toute règle, vous ne manquerez pas de trouver certaines exceptions. Il s’agit donc plutôt d’un ensemble de bonnes pratiques et de rappels afin d’éviter les pièges du cache. En espérant que cela vous permettra d’apprivoiser votre cache en toute tranquillité. N’oubliez pas que le cache est votre ami, il faut l’aimer aussi, comme nous il a une âme. Vos remarques sont les bienvenues pour étoffer ces règles et aider les futurs lecteurs dans la mise en place de leur(s) cache(s).

Ressources

• Varnish
• Apache
• Guava Cache
• Memcached
• Redis
• Nginx
• EHCache