Résumé

  • Fastly comptabilise séparément le défaut au cache de proximité et le succès au shield, même sans appel à l’origine. Le ratio affiché ne mesure pas directement les requêtes d’origine évitées.
  • Le trafic entre POP Fastly entre dans le nombre de requêtes et la bande passante facturable. Une économie globale reste possible, mais n’est pas démontrée pour chaque client.
  • Les en-têtes peuvent conserver un événement de shield antérieur, tandis que certains compteurs ne concernent que les réponses pouvant être mises en cache. Aucun ne constitue seul une facture.

L’unité d’acceptation doit être annoncée

L’équipe qui gère l’origine peut vouloir réduire ses appels. L’acheteur du CDN veut maîtriser ce qu’il paie. L’application doit satisfaire l’utilisateur. Ces objectifs se rencontrent, mais un taux de cache unique ne suffit pas à démontrer les trois.

Le guide conceptuel du shielding décrit précisément le cas qui les sépare. Une requête manque le cache du POP qui la reçoit, puis trouve le contenu dans un POP intermédiaire, le shield. Elle est satisfaite dans le réseau Fastly sans solliciter l’origine.

Pour le calcul du ratio, Fastly enregistre pourtant un défaut et un succès. Lorsqu’une requête atteint effectivement l’origine, il enregistre deux défauts, un à chaque étage. Une livraison et un événement de cache ne sont donc pas la même unité. Le ratio peut sembler plus bas que prévu alors que le shield a réalisé le travail voulu.

Cela ne rend pas automatiquement bon tout ratio faible. Un service peut avoir de vrais problèmes de clé de cache, de fraîcheur ou de demande. Moins d’appels à l’origine ne prouvent pas non plus un gain si moins d’utilisateurs réussissent à obtenir leur contenu. Aucun trafic client n’a été mesuré ici. Le mécanisme publié montre seulement pourquoi une seule valeur ne permet pas de conclure.

Un appel évité ailleurs ne devient pas un travail gratuit

Le guide de configuration précise que le trafic entrant au shield est facturé comme du trafic ordinaire, y compris pour alimenter d’autres POP. Le guide conceptuel inclut les trajets entre POP dans les requêtes et la bande passante facturable.

Un succès au shield peut donc épargner l’origine tout en conservant une étape payante du CDN. Ce ne sont pas deux descriptions contradictoires. L’architecture déplace du travail vers un cache partagé ; elle ne fait pas disparaître toute circulation parce que l’origine n’a rien reçu.

Fastly décrit un surcroît de bande passante susceptible d’être compensé par des économies de bande passante et de charge à l’origine. Le fournisseur indique aussi que shielding réduit souvent le coût global dans des configurations réalistes. Cette possibilité fait partie de l’intérêt du produit. Elle ne remplace pas une comparaison des conditions commerciales et du trafic du client.

Le cas extrême exposé est un service qui traite toutes les requêtes en PASS. Le nombre de requêtes et la bande passante de livraison peuvent alors presque doubler, puisque la plupart passent par deux POP. Ce n’est ni une règle de doublement de toute facture, ni la preuve d’une erreur de double facturation. Les remises, engagements, prix d’origine et volumes n’ont pas été examinés.

Comparer des périodes et des octets compatibles

Un tableau d’achat qui ne récompense que la hausse du ratio peut pénaliser le shield pour avoir ajouté une seconde décision au comptage. Un autre qui ne récompense que la baisse des appels d’origine peut omettre le trajet CDN supplémentaire. Chaque tableau peut lire correctement sa valeur et décrire incorrectement le contrat.

La comparaison utile garde une même période et une demande utilisateur explicitée. Elle sépare les requêtes d’origine et celles du shield, puis indique quels octets sont inclus. Un compteur de corps de réponse n’est pas un total corps et en-têtes. Un nombre de requêtes n’est pas un nombre de visiteurs uniques.

Il n’est pas nécessaire que tous les compteurs diminuent pour qu’un achat soit utile. Le rôle du shield est de redistribuer le travail. L’acceptation doit montrer pourquoi cette redistribution sert l’objectif de livraison et l’objectif économique, au lieu de demander à une métrique favorable de combler une preuve absente.

Deux noms de serveurs ne prouvent pas deux visites actuelles

Le guide conceptuel donne une limite de lecture importante. X-Served-By, X-Cache-Hits et X-Cache peuvent présenter plusieurs POP. Mais lors d’un succès au bord, l’entrée du shield peut provenir de l’événement antérieur qui a rempli le cache. Elle ne représente pas nécessairement une traversée du shield par la requête présente.

Compter chaque réponse à deux entrées comme un nouveau trajet facturable inventerait un événement actuel à partir d’une information historique. Les en-têtes restent utiles lorsqu’on garde leur sens, pas lorsqu’on les transforme en lignes de facture.

La référence X-Served-By avertit en outre que les identités de cache et codes de centres peuvent être réutilisés. Une identité précise à sa génération ne devient pas un identifiant permanent d’actif à comparer sans précaution entre deux dates. Cet article n’a recueilli aucun en-tête client et n’a sondé aucun service de livraison.

HIT et MISS simplifient plusieurs états

La référence X-Cache indique qu’un PASS est présenté comme MISS, qu’un contenu synthétique généré au bord est présenté comme HIT, et que les succès liés au contenu périmé ou à la revalidation en arrière-plan sont aussi HIT. Plusieurs entrées peuvent tenir à shielding, à Next-gen WAF at Edge ou à une reprise de traitement.

HIT ne doit donc pas devenir l’affirmation universelle qu’une requête actuelle a extrait exactement l’objet stocké que le lecteur imagine. L’explication des entrées non-MISS comme satisfaction depuis le cache, plutôt que transfert, comporte aussi une réserve pour la reprise. Retirer ces limites rendrait le récit plus simple mais moins exact.

La conséquence est commerciale, sans nécessiter de tutoriel de code : la présentation d’un en-tête n’est pas l’unité du contrat. Elle aide l’opérateur à comprendre une réponse ; elle ne permet pas à la finance d’additionner chaque entrée comme un travail courant indépendamment établi.

Les statistiques brutes ne suppriment pas les définitions

Les références analyses en temps réel et statistiques historiques séparent le shield et l’origine. Les compteurs de récupération cacheable concernent des requêtes terminées ayant renvoyé un contenu susceptible d’être mis en cache, pas toutes les requêtes possibles.

D’autres champs distinguent succès, défauts et octets de requête ou de réponse. Ils permettent de demander où le travail a eu lieu, si les unités et fenêtres restent cohérentes. Ils ne deviennent pas pour autant une facture, un calcul de gain net ou une preuve de performance client.

Le shield n’est pas mis en cause par ce raisonnement. Son effet doit être acheté et expliqué dans les bonnes unités. Un défaut au bord puis un succès au shield peuvent signifier simultanément une origine épargnée, un ratio portant un défaut supplémentaire et un trajet CDN payé. Une acceptation sérieuse peut conserver ces trois vérités.

Sources