Le "Dogpile effect"

L’utilisation  du cache pour stocker des données, peu importe leur provenance et le système de cache, est une  technique éprouvée. Tellement évidente et simple à mettre en place que  l’on ne se pose pas forcément de questions sur la mise à jour du contenu stocké en cache.

La  méthode la plus répandue consiste à essayer de récupérer les données en  cache, si elles ont expirées ou ne sont pas en cache alors on relance  le calcul et on met à jour le cache. Dans le cas d’une application web  le client qui arrivera au moment où le cache aura expiré devra juste  attendre un peu (parfois longtemps) qu’il soit  rafraîchi. Dans un contexte de forte charge, et/ou avec des données longues  à calculer, l’on va se retrouver avec plusieurs connexions arrivants au  moment où le cache est expiré et pas encore rafraîchi, ce qui aura pour  effet immédiat de lancer plusieurs fois la mise à jour du cache, de  charger la base de données, de faire monter les cpus de serveurs, l’utilisation de la mémoire, etc.  C’est cela que l’on nome le dogpile effect (terme, à priori, emprunter à l’argo du foot US pour désigner un tackle impliquant au moins 3 joueurs).

Différente technique « anti-dogpiling » existent pour sinon résoudre complètement ce problème, au moins limiter les risques qu’il ne se présente:

1. Mettre en place des tâches planifiées.
Cette  méthode est très simple à mettre en place, une ou plusieurs tâches  planifiées iront rafraîchir vos données en cache selon la fréquence que  vous aurez définie, les clients n’ayant plus à mettre à jour les  données, ont ne risque plus d’avoir de multiples demande de  rafraîchissement du cache. L’inconvénient et que toutes les données en  cache seront rafraîchies, qu’elles soient utiles ou non et qu’il est  toujours possible qu’un ou plusieurs clients se connectent alors que les  données ne sont pas présentent en cache (Memcache peut par exemple, de lui même, supprimer certaines données).

2. Verrouiller la procédure de mise à jour du cache.
L’on  peut aussi choisir de laisser aux clients la responsabilité de mettre à  jour le cache, dans ce cas pour éviter le dogpile effect l’on va poser  des verrous avant de relancer le calcul des données en utilisant, en fonction de votre architecture, le système  de fichier ou la base de données par exemple. Lorsque le verrou est  posé, les autres instances du clients qui essaient d’accéder aux données vont  attendre qu’elles soient mis à jour sans relancer le calcul. Cette méthode à  l’avantage de ne mettre à jour le cache que pour les données utilisées,  l’inconvénient et que même si la mise à jour du cache n’est lancée  qu’une fois, tous les clients sont bloqués et doivent attendre qu’elle  soit terminée.

3. Anticiper l’expiration du cache.
Cette  dernière méthode se rapproche de la seconde, la différence est que en  plus des données, l’on stockera également en cache le temps nécessaire  au calcul de ces données. Lorsqu’une requête sera faite, si la durée de  vie du cache restante est inférieure au temps nécessaire au  rafraîchissement du cache alors on posera les verrous et l’on lancera la  mise à jour du cache en asynchrone. L’avantage de cette technique est  qu’aucun client n’aura plus à attendre que le cache soit mis à jour, la  demande sera anticipé. L’inconvénient et qu’il faut tout de même garder  une solution de secours avec une des autre méthode dans le cas, par exemple, où aucun  appel ne serait fait dans le délai activant la mise à jour du cache.

About the Author: Guillaume Luchet

Guillaume Luchet est Directeur de la R&D et Lead Développeur chez Bilendi Technology, entrepreneur et développeur freelance.