C’est parce qu'il y a du cache ! Il faut le vider.
Le cache : source de nombreux problèmes. Omniprésent dans les conversations dès que tu travailles sur un produit web et excuse numéro 1 des développeurs qui veulent éviter un diagnostic.
Qu’est-ce qu’un cache ?
Un cache est un système, un logiciel, qui garde en mémoire le résultat d’un traitement. Pas besoin de réexécuter toute la chaîne, tu as déjà la réponse sous le coude.
Un cache peut contenir plein de choses : le résultat d’un traitement coûteux, des images, des vidéos, des données qui changent rarement etc...
Le but est d’améliorer la performance en réduisant :
-
Le temps de réponse : moins de traitement, proximité géographique avec le client...
Moins de délais = un client heureux et une amélioration du référencement par les moteurs de recherche. -
Les ressources mobilisées : puissance de calcul, charge sur les machines protégées par le cache...
Moins de ressources = moins de coûts.
Tu utilises des caches tous les jours !
Chaque affichage de page web déclenche des dizaines de caches répartis dans différents systèmes : ton navigateur web, ton fournisseur d'accès internet, l’hébergeur du site, les logiciels internes du site etc…
Avant même d’atteindre le site et son contenu, ton navigateur gère tout seul tout un tas de caches obscurs. Souviens-toi du DNS dont on parlait dans le second chapitre, il y a bien sûr du cache là-dessus.
Chaque couche de cache a son propre but, impliquant différentes technologies et nécessitant une stratégie de gestion dédiée.
Quelques exemples :
- Le site peut indiquer comment les navigateurs et les intermédiaires doivent cacher (mettre en cache) son contenu. C’est pour ça que quand tu visites de nouveau une page, elle se charge beaucoup plus vite que la première fois.
- Un réseau de diffusion de contenu, ou Content Delivery Network, est un réseau de machines réparties tout autour du monde. Les CDN visent à rapprocher géographiquement le contenu des clients, réduisant ainsi le temps de transfert sur le réseau. En gros, pour un client en Europe, sa requête va probablement être routée vers un serveur Européen. Les CDN sont particulièrement, mais pas seulement, utilisés sur les fichiers statiques : images, vidéos, design du site…
- Un proxy inverse est un serveur spécial qui réceptionne les requêtes pour protéger les serveurs applicatifs. Pas besoin d’exécuter le code si le proxy peut déjà fournir une réponse précalculée. Technologies les plus connues : Varnish, Nginx.
- Le cache applicatif. Nous allons l’explorer tout de suite plus en détail.
Le cache applicatif
Ce sont les systèmes de cache qui sont directement utilisés par le code écrit par les développeurs. Nous l’utilisons principalement pour réduire le nombre de communications en stockant :
- Les résultats des traitements en base de données.
- Les réponses des appels vers d’autres briques internes ou des partenaires.
Prenons un exemple :
- Tu veux afficher sur une page tes offres d’abonnement.
- Ton catalogue d’offres est hébergé chez un partenaire. Il peut mettre jusqu’à 5 secondes pour te répondre, c’est-à-dire une éternité dans la navigation d’un client.
- Tu veux proposer des offres différentes à un client Européen et à un client Américain.
Les offres ne changent pas tous les jours, on décide donc de les mettre en cache. Ça évite l’appel de 5 secondes.
À quel moment on met en cache ? Deux stratégies possibles : le premier client qui arrive déclenche la requête et se mange les 5 secondes d’attente. C’est généralement ce qu’on fait 🙈. Ou alors, on est gentil et on développe un script qui prérempli le cache. On appelle ça du préchauffage (warmup).
Le monde étant méchant, on va laisser faire le premier client 😈.
La cinématique complète pour lui :
- Il charge la page avec toutes les offres.
- On détecte ce client comme étant Européen. On regarde si les offres Européennes sont déjà dans le cache. Non ❌.
- On demande au partenaire de nous fournir les offres Européennes. Il répond au bout de 5 secondes.
- La réponse est stockée dans le cache.
- La réponse est retournée au client pour qu’il puisse voir les offres sur la page.
Le second client arrive :
- Il charge la page avec toutes les offres.
- On détecte ce client comme étant Européen. On regarde si les offres Européennes sont déjà dans le cache. Oui ✅.
- La réponse est retournée au client pour qu’il puisse voir les offres sur la page.
On a gagné 5 secondes par client 🥳 ! Enfin, pour les Européens… Le premier client Américain va lui aussi devoir attendre 5 secondes.
Dans notre exemple, le cache est segmenté par un seul critère : le continent. C’est une liste finie dont on connaît les valeurs. On aurait pu facilement préchauffer le cache. C’est loin d’être toujours le cas ! On pourrait segmenter les offres selon de multiples critères : le client est déjà abonné on ne veut lui proposer que de l’upgrade, le client a résilié son abonnement il faut essayer de le retenir, ce client a déjà bénéficié d’une promotion donc il ne faut pas lui en proposer une nouvelle…
😱 Quel enfer !
Et si un cache est difficile à préchauffer, il sera aussi difficile à vider.
La suppression du cache
Il y a seulement deux choses difficiles en informatique : l’invalidation du cache et nommer les choses <Phil KARLTON>
Cas 1 : Le cache partagé par plusieurs clients
Reprenons l’exemple sur les offres. Tu crées une nouvelle offre destinée aux Américains dans le back office de ton partenaire. Tu vas avoir besoin de vider le cache des offres pour que les clients puissent y avoir accès.
Premier problème : comment ton site est au courant que quelque chose a changé chez le partenaire ? 😅
Deux solutions : soit tu interroges régulièrement le partenaire pour voir si quelque chose a changé, soit il est capable de t'envoyer l’événement “une nouvelle offre a été créée”. Dans les 2 cas, il y a besoin de mettre en place une communication.
Deuxième problème : si tu vides le cache et qu’il met 5 secondes à se reconstruire, les milliers de clients actuellement sur le site vont tous simultanément déclencher une requête vers le partenaire.
Supprimer un cache, c’est comme ouvrir la grille du magasin un matin de soldes. En enlevant la protection, tu exposes tout le système à un énorme pic de trafic instantané.
Les solutions : éviter de supprimer du cache pendant des moments d’affluence, préchauffer au maximum, supprimer juste le nécessaire.
Troisième problème : c’est quoi “juste le nécessaire” ?
En ajoutant les autres critères cités précédemment, la nouvelle offre peut nécessiter de vider plusieurs caches. C’est généralement la mauvaise suppression de l’un d’eux qui donne des cheveux blancs aux développeurs. Le pire, c’est quand les caches doivent être supprimés dans un certain ordre car le calcul de l’un dépend de l’autre.
Cas 2 : le cache propre à un client
Supposons qu’au moment de la connexion du client sur l’application mobile, tu ailles récupérer tout un tas de données sur lui : historique de paiement etc... Tu mets en cache ces données pour qu’elles soient disponibles rapidement pendant la navigation.
Problème : sauf si quelque chose est modifié sur son profil, les données de ce client prendront de la place dans le cache indéfiniment.
C’est pour ça que la plupart des systèmes de cache donnent la possibilité de mettre un délai d’expiration. Au moment de créer l’entrée dans le cache, tu peux indiquer par exemple “je veux que cette entrée expire dans 3 heures”. Ce n’est pas si facile que ça en a l’air ! Un délai trop court : ton cache est inutile. Un délai trop long : tu risques de surcharger la mémoire.