Zusammenfassung

  • Fastly zählt Edge-Miss und Shield-Hit getrennt, obwohl dabei keine Origin-Anfrage notwendig ist. Die aggregierte Trefferquote ist nicht direkt die Quote vermiedener Origin-Aufrufe.
  • Verkehr zwischen Fastly-POPs gehört zur Anfragezahl und abrechenbaren Bandbreite. Ein möglicher Gesamtvorteil ist kein gemessener Spareffekt für jede Kundenrechnung.
  • Header können einen früheren Shield-Vorgang enthalten; bestimmte Fetch-Metriken zählen nur cachefähige Inhalte. Beides ist weder eine Rechnung noch ein universeller aktueller Pfadnachweis.

Eine Lieferung hat mehrere Cache-Entscheidungen

Wer den Origin betreibt, möchte möglicherweise weniger Abrufe. Wer CDN-Auslieferung kauft, muss die veränderten Kosten verstehen. Die Anwendung braucht einen zufriedenstellenden Nutzererfolg. Eine Trefferquote wirkt wie ein gemeinsames Ziel, beweist diese drei Ergebnisse aber nicht.

Fastlys Shielding-Konzeptbeschreibung liefert einen konkreten Fall. Am empfangenden Edge-POP fehlt das Objekt. Die Anfrage geht an einen zwischengeschalteten Shield-POP, der es im Cache hat. Der Inhalt wird innerhalb Fastlys geliefert, ohne den Origin aufzurufen.

Für die Quote werden trotzdem ein Miss am Edge und ein Hit am Shield erfasst. Eine Anfrage, die bis zum Origin gelangt, zählt als zwei Misses. Eine Auslieferung und ein Cache-Ereignis sind unterschiedliche Einheiten. Die ausgewiesene Quote kann niedriger aussehen als erwartet, obwohl der Shield die gewünschte Origin-Entlastung leistet.

Das macht eine niedrige Quote nicht immer gut. Cache-Schlüssel, Frische oder Verkehrszusammensetzung können tatsächlich problematisch sein. Auch weniger Origin-Anfragen beweisen keinen Vorteil, wenn weniger Nutzer erfolgreich Inhalt erhalten. Hier wurde kein Kundenverkehr gemessen. Die veröffentlichte Zählweise zeigt lediglich die Grenze einer einzigen Kennzahl.

Geschonter Origin bedeutet nicht verschwundene CDN-Arbeit

Die Konfigurationsanleitung erklärt eingehenden Shield-Verkehr als regulär berechneten Verkehr, einschließlich des Befüllens anderer POPs. Die Konzeptbeschreibung nimmt Kommunikation zwischen Fastly-POPs ausdrücklich in Anfragezahl und abrechenbare Bandbreite auf.

Ein Shield-Hit kann somit einen Origin-Abruf vermeiden und gleichzeitig einen bezahlten CDN-Abschnitt behalten. Das widerspricht sich nicht. Die Architektur verändert den Ort der Arbeit; sie beseitigt nicht jede Übertragung, nur weil der Origin keine Anfrage erhält.

Fastly beschreibt zusätzliche Bandbreitenentgelte, die wahrscheinlich durch eingesparte Origin-Bandbreite und Serverlast ausgeglichen werden, und nennt häufige Gesamtersparnisse in realistischen Szenarien. Dieser mögliche Nutzen ist wichtig. Ein konkreter Kundenvergleich braucht jedoch die Verkehrsstruktur und kommerziellen Bedingungen auf beiden Seiten.

Der dokumentierte Extremfall ist ein Dienst, der jede Anfrage als PASS behandelt. Anfragezahl und Auslieferungsbandbreite verdoppeln sich dann nahezu, weil die meisten Anfragen zwei POPs erreichen. Das ist keine universelle Verdoppelung der Geldrechnung und kein Befund einer fehlerhaften Doppelberechnung. Rabatte, Zusagen, Origin-Preise und tatsächliche Mengen wurden nicht untersucht.

Die Vergleichsbasis entscheidet mit

Eine Einkaufsbewertung, die allein eine höhere Trefferquote belohnt, kann einen nützlichen Shield wegen der zweiten gezählten Entscheidung benachteiligen. Eine Bewertung, die nur weniger Origin-Aufrufe belohnt, kann den zusätzlichen CDN-Abschnitt ausblenden. Beide können ihre Zahl richtig lesen und den Kauf falsch erklären.

Eine brauchbare Abnahme hält Nutzernachfrage und Zeitraum ausdrücklich fest, trennt Origin- und Shield-Aktivität und benennt die Bytes jedes Felds. Antwortkörperbytes sind nicht automatisch die Summe aus Körper und Headern. Eine Anfragezahl ist keine Zahl eindeutiger Nutzer. Ähnliche Bezeichnungen erlauben keinen Einheitenwechsel.

Es müssen nicht alle Zähler fallen. Die Zwischenstufe soll Arbeit umverteilen. Zu belegen ist, weshalb die Umverteilung das Auslieferungsziel und das wirtschaftliche Ziel erfüllt. Eine günstige Kennzahl darf dabei nicht einen fehlenden Nachweis ersetzen. Ein numerischer Kundenspareffekt wird hier nicht berichtet.

Zwei Header-Einträge können eine Vergangenheit enthalten

Die Konzeptbeschreibung nennt eine subtile Grenze: X-Served-By, X-Cache-Hits und X-Cache können mehrere POPs zeigen. Bei einem aktuellen Edge-Hit kann der Shield-Eintrag aber aus dem früheren Vorgang stammen, der das Objekt ursprünglich gecacht hat. Er zeigt dann nicht einen neuen Shield-Besuch dieser Anfrage.

Jede Antwort mit zwei Einträgen als neuen abrechenbaren Weg zu zählen würde aus historischer Information ein aktuelles Ereignis erfinden. Der Header bleibt nützlich, wenn seine zeitliche Bedeutung erhalten bleibt; seine Einträge sind nicht eigenständig erwiesene Rechnungspositionen.

Die X-Served-By-Referenz warnt außerdem vor wiederverwendeten Cache-Identitäten und Standortcodes. Ein bei der Erzeugung genauer Name ist kein dauerhafter Inventarschlüssel für Vergleiche über verschiedene Zeiten. Kundenheader oder Kunden-CDN-Pfade wurden nicht erfasst.

HIT und MISS verkürzen verschiedene Zustände

Die X-Cache-Referenz meldet PASS als MISS und am Edge erzeugten synthetischen Inhalt als HIT. Auch Treffer für veralteten Inhalt oder Hintergrund-Revalidierung erscheinen als HIT. Mehrere Einträge können von Shielding, Next-gen WAF at Edge oder einem Verarbeitungsneustart stammen.

HIT bedeutet also nicht universell, dass die aktuelle Anfrage genau das vorgestellte gespeicherte Objekt abgeholt hat. Die Erklärung von Nicht-MISS-Einträgen als Cache-Erfüllung statt Weiterleitung enthält zudem eine Neustart-Ausnahme. Diese Einschränkungen zu entfernen macht die Geschichte einfacher, nicht den Beleg genauer.

Die wirtschaftliche Bedeutung verlangt kein Programmiertutorial. Die Headerdarstellung ist nicht die vertragliche Abrechnungseinheit. Sie hilft dem Betrieb bei einer Antwort, erlaubt Finance aber nicht, ihre Einträge als jeweils bewiesene aktuelle Arbeit zu summieren.

Rohdaten behalten ihre Definitionen

Die Referenzen für Echtzeitanalyse und historische Statistiken unterscheiden Shield und Origin. Cache-Fetch-Felder betreffen abgeschlossene Abrufe, die cachefähigen Inhalt zurückgaben; sie zählen nicht sämtliche denkbaren Anfragen.

Weitere Felder trennen Hits, Misses sowie Anfrage- und Antwortbytes. Mit übereinstimmenden Zeitfenstern und Einheiten lässt sich fragen, wo die Arbeit stattfand. Daraus entsteht nicht automatisch eine Rechnung, eine Nettoersparnis oder ein Leistungstest.

Das Argument richtet sich nicht gegen Shielding. Gekauft werden sollte sein wirklicher Effekt: erfolgreiche Auslieferung mit umverteilter Arbeit. Edge-Miss und Shield-Hit können gleichzeitig einen geschonten Origin, eine Quote mit zusätzlichem Miss und bezahlten CDN-Verkehr beschreiben. Eine gute Abnahme hält alle drei Aussagen zusammen.

Quellen