Qu’est-ce que le taux de succès du cache ?

Le taux de succès du cache est la proportion de requêtes auxquelles un cache répond à partir d’une réponse stockée au lieu de les transmettre à l’origine. Il est généralement calculé par requête, et parfois par octet livré. Les outils diffèrent quant à la prise en compte des requêtes ne pouvant pas être mises en cache et des réponses revalidées : deux taux rapportés ne sont donc comparables que si leurs définitions concordent.

Un succès signifie que le cache a répondu à la requête à partir d’une réponse stockée sans la transmettre. La RFC 9211 normalise la manière dont un cache le signale sur chaque réponse dans l’en-tête Cache-Status : hit lorsque la requête n’a pas été transmise, ou fwd avec une raison telle que uri-miss, vary-miss, stale ou bypass lorsqu’elle l’a été. Un taux repose sur le décompte de ces résultats pour une période et un ensemble de requêtes choisis. Trois facteurs le déterminent principalement : la durée pendant laquelle les réponses restent fraîches, le nombre de clés de cache distinctes entre lesquelles un même contenu est réparti, et la fréquence à laquelle un objet est demandé à un emplacement de cache, qui doit être suffisante pour qu’il soit encore stocké à l’arrivée de la requête suivante. Les emplacements en périphérie remplissent leurs caches séparément : la première requête pour un objet à chaque emplacement ne le trouve donc pas dans le cache local ; un niveau supérieur partagé peut y répondre sans contacter l’origine.

Les requêtes ne pouvant pas être mises en cache figurent-elles au dénominateur ? Cela dépend de l’outil. La métrique Cache hit rate d’Amazon CloudFront ne compte que les requêtes pouvant être mises en cache et exclut POST, PUT et les erreurs, tandis que son rapport de statistiques du cache présente les succès, les absences en cache et les erreurs en pourcentage de toutes les requêtes des utilisateurs. Un article de l’équipe d’ingénierie de Fastly consacré à Varnish utilise la définition plus restreinte, soit les succès divisés par la somme des succès et des absences en cache, et appelle couverture du cache la part des requêtes pouvant être mises en cache. Vérifiez le dénominateur avant de comparer deux tableaux de bord ou de fixer un objectif.
Une réponse revalidée compte-t-elle comme un succès du cache ? Pas selon la RFC 9211 : une réponse stockée périmée dont la validation a nécessité une transmission vers l’origine est signalée comme fwd=stale, même lorsque l’origine répond 304 et que le corps stocké est réutilisé. Les fournisseurs adoptent des approches différentes. Cache Analytics de Cloudflare compte les requêtes revalidées comme servies par l’origine dans sa vue Requests, mais comme servies par Cloudflare dans sa vue Data Transfer. Le graphique de statistiques du cache de CloudFront n’inclut pas les succès après actualisation, son terme pour les requêtes visant des objets expirés encore présents dans le cache en périphérie.
Requêtes ou octets ? Ils répondent à des questions différentes. Un taux calculé par requête donne le même poids à chaque requête, qu’elle transporte quelques octets ou de nombreux mégaoctets, et indique à quelle fréquence un utilisateur doit attendre une réponse de l’origine. Un taux calculé par octet représente la part des octets livrés aux clients qui proviennent de succès du cache. Un site dont les petits fichiers sont trouvés en cache tandis que les gros fichiers multimédias en sont absents peut afficher un taux élevé par requête et faible par octet. Dans les deux cas, le taux est une proportion, pas une quantité : la plupart des hébergeurs facturent le trafic sortant selon les données envoyées par leurs serveurs, et cette quantité peut augmenter avec le trafic alors que le taux reste stable. Pour les décisions relatives aux coûts, examinez un chiffre calculé par octet conjointement avec les octets provenant de l’origine. La vue Data Transfer de Cloudflare compte les données transférées plutôt que les requêtes ; le rapport de statistiques du cache de CloudFront fournit BytesFromMisses, qu’AWS décrit comme une bonne approximation des octets récupérés depuis l’origine, mais qui exclut les objets expirés encore présents dans le cache en périphérie.
Pourquoi le taux est-il faible alors que les règles de mise en cache semblent correctes ? Une fois les durées de validité du cache écartées comme cause, vérifiez d’abord la fragmentation des clés de cache. Lorsque CloudFront met en cache selon les paramètres de la chaîne de requête, il stocke ?a=1&b=2 et ?b=2&a=1 comme des objets distincts. Il en va de même pour les différences de casse des paramètres et pour chaque valeur distincte d’un cookie ou d’un en-tête, tel que User-Agent, sur lequel il est configuré pour baser sa mise en cache. Par ailleurs, une réponse ne peut être réutilisée que tant qu’elle est encore stockée, et seulement si elle est fraîche, revalidée avec succès auprès de l’origine ou autorisée à être servie alors qu’elle est périmée, par exemple avec stale-while-revalidate ou stale-if-error. Les caches évacuent les objets peu demandés, et chaque emplacement en périphérie remplit son propre cache. Des durées de validité plus longues et un niveau de cache supérieur partagé, tel que CloudFront Origin Shield ou Cloudflare Tiered Cache, réduisent les requêtes vers l’origine.

Suivez le taux de succès du cache lorsque chaque requête non satisfaite par le cache entraîne une latence à l’origine, une charge sur l’origine ou un traitement à la demande. Un taux en baisse peut signaler de courtes durées de validité du cache ou une fragmentation des clés de cache selon les chaînes de requête, les cookies ou les en-têtes de requête. Si l’outil compte toutes les requêtes, une valeur faible est normale pour un trafic majoritairement non stockable en cache ; s’il compte uniquement les requêtes pouvant être mises en cache, ce même trafic peut tout de même afficher une valeur élevée.

Sur le Smart CDN de Transloadit, une absence en cache entraîne davantage de travail que sur un CDN qui stocke uniquement des fichiers existants : elle provoque l’importation de l’original et l’exécution de votre Template, tandis qu’un succès du cache ne répète que l’étape de livraison depuis la périphérie. La documentation du Robot /tlcdn/deliver décrit la livraison depuis le cache comme réduisant la latence et le volume d’encodage. Le taux de succès du cache pour vos URL du Smart CDN influe donc à la fois sur la latence et sur l’utilisation. Pour les URL signées, la durée de validité effective du cache est limitée par la durée de validité restante de la signature : une durée plus courte pour exp réduit donc la réutilisation.

Les pages liées ici ne définissent pas de rapport sur le taux de succès du cache et ne précisent pas quelles requêtes il compterait. La présentation du Smart CDN suggère d’examiner les en-têtes de réponse du cache lors du débogage ; si vous calculez un taux à partir de ces en-têtes, consignez votre propre définition d’un succès du cache.

Explorer les capacités de diffusion de Transloadit

Qu’est-ce que le taux de succès du cache ?

Fonctionnement du taux de succès du cache

Points clés

Quand le taux de succès du cache est important

L’apport de Transloadit au taux de succès du cache

Références

Transformer vos connaissances sur les médias en une chaîne de traitement opérationnelle