Novembre 21 2022

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

Cache Control est un en-tête HTTP qui peut aider à informer les serveurs de cache comme Varnish de la durée de vie du cache.

Print Friendly, PDF & Email

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.

Vous avez des doutes ? Vous ne savez pas par où commencer ? Contactez-nous


Nous avons toutes les réponses à vos questions pour vous aider à faire le bon choix.

Discute avec nous

Discutez directement avec notre support avant-vente.

0256569681

Contactez-nous par téléphone pendant les heures de bureau 9h30 - 19h30

Contactez-nous en ligne

Ouvrez une demande directement dans l'espace contact.

INFORMATIONS

ManagedServer.it est le premier fournisseur italien de solutions d'hébergement hautes performances. Notre modèle d'abonnement est abordable et prévisible, afin que les clients puissent accéder à nos technologies d'hébergement fiables, à nos serveurs dédiés et au cloud. ManagedServer.it offre également d'excellents services d'assistance et de conseil sur l'hébergement des principaux CMS Open Source tels que WordPress, WooCommerce, Drupal, Prestashop, Magento.

JUSTE UN MOMENT !

Souhaitez-vous voir comment votre WooCommerce fonctionne sur nos systèmes sans avoir à migrer quoi que ce soit ? 

Entrez l'adresse de votre site WooCommerce et vous obtiendrez une démonstration navigable, sans avoir à faire absolument quoi que ce soit et entièrement gratuite.

Non merci, mes clients préfèrent le site lent.
haut