Was ist die Cache-Trefferquote?

Die Cache-Trefferquote ist der Anteil der Anfragen, die ein Cache mit einer gespeicherten Antwort beantwortet, statt sie an den Origin-Server weiterzuleiten. Sie wird meist pro Anfrage und manchmal pro ausgeliefertem Byte ermittelt. Tools unterscheiden sich darin, ob nicht zwischenspeicherbare Anfragen und revalidierte Antworten mitzählen. Zwei gemeldete Quoten sind daher nur vergleichbar, wenn ihre Definitionen übereinstimmen.

So funktioniert die Cache-Trefferquote

Ein Treffer bedeutet, dass der Cache die Anfrage mit einer gespeicherten Antwort beantwortet hat, ohne sie weiterzuleiten. RFC 9211 standardisiert, wie ein Cache dies bei jeder Antwort im Header Cache-Status meldet: hit, wenn die Anfrage nicht weitergeleitet wurde, oder fwd mit einem Grund wie uri-miss, vary-miss, stale oder bypass, wenn sie weitergeleitet wurde. Eine Quote ergibt sich aus der Zählung dieser Ergebnisse für ein gewähltes Zeitfenster und eine gewählte Menge von Anfragen. Drei Faktoren bestimmen sie hauptsächlich: wie lange Antworten frisch bleiben, auf wie viele unterschiedliche Cache-Schlüssel derselbe Inhalt verteilt ist und ob ein Objekt an einem Cache-Standort oft genug angefordert wird, um bei der nächsten Anfrage noch gespeichert zu sein. Edge-Standorte füllen ihre Caches unabhängig voneinander. Deshalb führt die erste Anfrage für ein Objekt an jedem Standort dort zu einem Cache-Miss. Eine gemeinsam genutzte übergeordnete Cache-Ebene kann sie beantworten, ohne den Origin-Server zu kontaktieren.

Wichtige Fakten

  1. Stehen nicht zwischenspeicherbare Anfragen im Nenner? Das hängt vom Tool ab. Die Metrik Cache hit rate von Amazon CloudFront zählt nur zwischenspeicherbare Anfragen und schließt POST, PUT und Fehler aus. Der Cache-Statistikbericht zeigt dagegen Treffer, Cache-Misses und Fehler als prozentuale Anteile aller Zuschaueranfragen. Ein technischer Artikel von Fastly über Varnish verwendet die engere Definition: Treffer geteilt durch die Summe aus Treffern und Cache-Misses. Den Anteil der überhaupt zwischenspeicherbaren Anfragen bezeichnet er als Cache-Abdeckung. Prüfen Sie den Nenner, bevor Sie zwei Dashboards vergleichen oder einen Zielwert festlegen.
  2. Ist eine revalidierte Antwort ein Treffer? Nicht nach RFC 9211: Eine nicht mehr frische gespeicherte Antwort, deren Anfrage zur Validierung weitergeleitet werden musste, wird als fwd=stale gemeldet, selbst wenn der Origin-Server mit 304 antwortet und der gespeicherte Antwortkörper erneut verwendet wird. Anbieter handhaben das unterschiedlich. Cache Analytics von Cloudflare zählt revalidierte Anfragen in der Anfrageansicht als vom Origin-Server ausgeliefert, in der Datentransferansicht jedoch als von Cloudflare ausgeliefert. Das Cache-Statistikdiagramm von CloudFront enthält keine Refresh-Treffer. So nennt CloudFront Anfragen nach abgelaufenen Objekten, die noch im Edge-Cache liegen.
  3. Anfragen oder Bytes? Sie beantworten unterschiedliche Fragen. Eine anfragebasierte Quote gewichtet jede Anfrage gleich, unabhängig davon, ob sie wenige Bytes oder viele Megabytes überträgt, und erfasst, wie oft ein Zuschauer auf den Origin-Server wartet. Eine bytebasierte Quote ist der Anteil der an Clients ausgelieferten Bytes, die aus Cache-Treffern stammen. Eine Website, deren kleine Dateien Cache-Treffer erzielen, deren große Mediendateien jedoch Cache-Misses verursachen, kann eine hohe anfragebasierte und eine niedrige bytebasierte Quote aufweisen. Beide Quoten sind Anteile, keine Datenmengen: Die meisten Hosting-Anbieter berechnen ausgehenden Datenverkehr nach der von ihren Servern gesendeten Datenmenge. Diese Menge kann mit dem Datenverkehr wachsen, während die Quote gleich bleibt. Betrachten Sie für Kostenentscheidungen eine bytebasierte Kennzahl zusammen mit der vom Origin-Server übertragenen Datenmenge. Die Datentransferansicht von Cloudflare zählt übertragene Daten statt Anfragen. Der Cache-Statistikbericht von CloudFront liefert BytesFromMisses. AWS bezeichnet diesen Wert als gute Näherung für die vom Origin-Server abgerufenen Bytes; er schließt jedoch abgelaufene Objekte aus, die noch im Edge-Cache lagen.
  4. Warum ist die Quote niedrig, obwohl die Caching-Regeln richtig aussehen? Sobald die Cache-Gültigkeitsdauer als Ursache ausgeschlossen ist, prüfen Sie zuerst die Fragmentierung der Cache-Schlüssel. Wenn CloudFront anhand von Query-String-Parametern zwischenspeichert, speichert es ?a=1&b=2 und ?b=2&a=1 als getrennte Objekte. Dasselbe gilt für Unterschiede in der Groß- und Kleinschreibung der Parameter sowie für jeden unterschiedlichen Wert eines Cookies oder Headers, etwa User-Agent, den die Konfiguration beim Caching berücksichtigt. Darüber hinaus lässt sich eine Antwort nur erneut verwenden, solange sie noch gespeichert ist, und nur, wenn sie frisch ist, erfolgreich beim Origin-Server revalidiert wurde oder trotz abgelaufener Gültigkeit ausgeliefert werden darf, etwa unter stale-while-revalidate oder stale-if-error. Caches verdrängen selten angeforderte Objekte, und jeder Edge-Standort füllt seinen eigenen Cache. Längere Gültigkeitsdauern und eine gemeinsam genutzte übergeordnete Cache-Ebene wie CloudFront Origin Shield oder Cloudflare Tiered Cache reduzieren Anfragen an den Origin-Server.

Wann die Cache-Trefferquote wichtig ist

Verfolgen Sie die Trefferquote, wenn jeder Cache-Miss Latenz durch einen Zugriff auf den Origin-Server, Last am Origin-Server oder Verarbeitung bei Bedarf verursacht. Eine sinkende Quote kann auf kurze Cache-Lebensdauern oder unterschiedliche Cache-Schlüssel durch Query-Strings, Cookies oder Anfrage-Header hindeuten. Zählt das Werkzeug jede Anfrage, ist bei überwiegend nicht cachebarem Datenverkehr ein niedriger Wert zu erwarten; zählt es nur cachebare Anfragen, kann derselbe Datenverkehr dennoch einen hohen Wert aufweisen.

Wie Transloadit bei der Cache-Trefferquote hilft

Bei Transloadits Smart CDN verursacht ein Cache-Miss mehr Arbeit als bei einem CDN, das nur vorhandene Dateien speichert: Er importiert das Original und führt Ihr Template aus, während ein Treffer nur den Auslieferungsschritt vom Edge-Standort wiederholt. Die Dokumentation zum Robot /tlcdn/deliver beschreibt, dass die Auslieferung aus dem Cache Latenz und Encoding-Volumen spart. Die Trefferquote Ihrer URLs von Smart CDN beeinflusst daher sowohl die Latenz als auch die Nutzung. Bei signierten URLs ist die effektive Cache-Gültigkeitsdauer durch die verbleibende Gültigkeitsdauer der Signatur begrenzt. Ein kürzerer Wert für exp verringert daher die Wiederverwendung.

Die hier verlinkten Seiten definieren weder einen Bericht zur Trefferquote noch geben sie an, welche Anfragen er zählen würde. Die Übersicht zu Smart CDN empfiehlt, bei der Fehlersuche die Cache-Antwortheader zu prüfen. Wenn Sie daraus eine Quote berechnen, dokumentieren Sie Ihre eigene Definition eines Treffers.

Entdecken Sie Transloadits Möglichkeiten zur Auslieferung

Quellen

Machen Sie aus Medienwissen eine funktionierende Pipeline

Verbinden Sie Uploads, Verarbeitung, KI, Storage und Auslieferung über eine deklarative API – um Encoding-Stack, Skalierung und ständig wechselnde Formate müssen Sie sich nicht selbst kümmern.

Transloadit kostenlos ausprobieren