Vernis et Cache Control, comment bien maîtriser la durée du Cache

Introduction

Vernis Cache est un proxy inverse HTTP et un accélérateur HTTP populaires. Il se trouve devant nos services Web/applicatifs et utilise une gamme de techniques de mise en cache, de prélecture et de compression pour réduire la charge sur les services backend en amont et fournir à nos clients des temps de réponse améliorés.

En plus d'améliorer les performances, une fonctionnalité peut-être moins connue de Varnish est qu'il peut être configuré pour protéger les clients contre les pannes et les pannes en amont. Si un service en amont est temporairement indisponible ou commence à échouer, Varnish peut se replier pour fournir des réponses obsolètes à partir de son cache, à condition que la période de grâce des objets mis en cache n'ait pas expiré.

Nous pouvons désormais affirmer sans en faire un secret que Varnish Cache est la base de notre infrastructure et de nos services Hosting Performance.

Contrôle du cache

Le rôle cache-controlde l'en-tête est d'indiquer aux caches en aval (navigateurs et caches proxy comme Varnish) comment mettre en cache les réponses. La valeur de s-maxagepermet à Varnish de connaître le nombre de secondes pendant lesquelles la réponse peut être mise en cache, également appelée durée de vie (TTL). La valeur de max-ageil sera utilisé par les caches du navigateur (et aussi par les caches proxy au cas où s-maxagenon précisé). Interne au vernis, la valeur est utilisée pour définir la beresp.ttlvariable.

Il stale-while-revalidateLa valeur informe le cache de la durée pendant laquelle il est acceptable de réutiliser une réponse obsolète. Dans l'exemple ci-dessus, la réponse deviendra périmée après 10 m (600 s), de sorte que le cache peut la réutiliser pour toute requête effectuée dans les 2 prochains jours (172800 XNUMX s). Ceci est également connu sous le nom de période de grâce, interne à Varnish la valeur est utilisée pour définir le beresp.gracevariable. La première réponse récupérée pendant la période de grâce déclenchera une requête de récupération en arrière-plan asynchrone, rendant l'objet mis en cache à nouveau frais, sans transmettre le coût de latence de la revalidation au client.

De plus, si le service backend est en panne ou répond lentement, les clients seront protégés contre de telles réponses jusqu'à l'expiration de la période de grâce, ce qui, espérons-le, donnera au service suffisamment de temps pour récupérer, ou aux ingénieurs suffisamment de temps pour résoudre un problème, avant qu'il n'affecte négativement le client. vivre. Il ne faut pas oublier qu'il s'agit d'un compromis : s'il fournit des réponses plus rapides et une plus grande résilience, il augmente également les chances de fournir des réponses obsolètes, voire incorrectes.

Le réglage d'un stale-while-revalidateune durée de vie élevée est un jugement et peut ne pas être appropriée pour les réponses contenant des données hautement dynamiques rendues côté serveur, où la fraîcheur est essentielle. Nous avons essayé de maximiser l'utilisation de la fonctionnalité sur les réponses contenant des données relativement statiques, telles que notre contenu éditorial et les pages de destination des catégories.

Configuration du vernis

Par défaut, Varnish fournira une réponse obsolète pendant la période de grâce s'il ne peut pas se connecter au service backend ou si la demande expire. Le comportement peut être étendu aux erreurs 5xx avec le code suivant danssub vcl_backend_response

sous vcl_backend_response {    si (beresp.status >= 500 && bereq.is_bgfetch) { 
        retour (abandon); 
    }    .... 
}

beresp.statuscontient le code de statut renvoyé par le service backend, bereq.is_bgfetchsera vrai si la requête backend a été envoyée de manière asynchrone après que le client a reçu une réponse mise en cache et return (abandon)ordonne à Varnish d'abandonner la demande et de ne rien faire.

En conclusion

Une réponse en cache obsolète, si elle est disponible, offrira dans la plupart des cas une meilleure expérience client qu'une page d'erreur. Lorsque le contenu rendu côté serveur est suffisamment statique pour permettre à stale-while-revalidatehaute durabilité, la mise en cache peut être un outil utile pour augmenter sa résilience.