Zusammenfassung

  • Request Collapsing verbindet gleichzeitige Anfragen für dasselbe geeignete Objekt mit einem Origin-Abruf. Es reduziert mögliche Wiederholungen und erzeugt eine Warteliste.
  • Fehlen eine wiederverwendbare Antwort und ein Hit-for-pass-Marker, können sich Warteschlangen neu bilden und Abrufe nacheinander statt parallel erfolgen.
  • Weniger Origin-Abrufe beweisen weder Gesamtersparnis noch bessere Lieferung. Auch Kontrollen gegen das Warten haben Kapazitäts- und Frischefolgen.

Der Schalter betrifft mehr als die Warteschlange

Eine Warteliste ist sichtbar, also scheint ein Abschalten der Bündelung ein enger Eingriff zu sein. Bei Fastly ist zumindest eine dokumentierte CDN-VCL-Kontrolle breiter: req.hash_ignore_busy schließt Anfragen vom Request Collapsing aus, lässt einen Treffer in einem frischen Cacheobjekt aber weiterhin zu.

Gleichzeitig macht die Kontrolle veraltete Objekte unbrauchbar. Die Wirkungen von stale-while-revalidate und stale-if-error werden deaktiviert. Ein Eingriff gegen Warteschlangen kann damit auch eine zulässige Auslieferungsoption bei Problemen am Origin entfernen.

Für Käufer ist das eine Erinnerung an die tatsächliche Entscheidungsgrenze. Wartezeit, Origin-Last und zulässige Aktualität gehören zusammen, sind aber nicht dasselbe. Keine dieser Einstellungen wurde für diesen Artikel angewendet oder getestet.

Die öffentliche Dokumentation beschreibt Mechanismen, keine gemessene Rechnung oder Kundenerfahrung. Gerade deshalb sollte eine günstige Kennzahl nicht als Beleg für Folgen dienen, die sie nicht erfasst.

Wiederholte Arbeit wird durch gemeinsames Warten ersetzt

Fastly definiert Request Collapsing als Zusammenführung gleichzeitiger Anfragen für dasselbe Objekt zu einem Abruf am Origin, dessen Antwort anschließend möglicherweise die wartenden Anfragen bedienen kann.

Läuft ein stark nachgefragtes Objekt im Cache ab, können unabhängige Abrufe einen Ansturm auf den Origin erzeugen. Die Warteliste lässt eine spätere geeignete Anfrage einem bereits laufenden Abruf folgen, statt eine weitere Kopie der Arbeit zu starten.

Ist die Antwort wiederverwendbar, kann ein Abruf mehrere nützliche Auslieferungen abschließen. Die Last kann sinken und gleichmäßiger werden. Die beteiligten Nutzer warten nun allerdings auf den Fortschritt derselben Beschaffung. Die Bildung der Gruppe beweist noch nicht, dass deren Ergebnis für alle geeignet ist.

Dabei geht es nicht um eine weltweite einzige Warteschlange für jede sichtbare URL. Maßgeblich sind Cacheobjekt, Variante und der anwendbare Auslieferungspfad. Fastly erläutert, dass Hit-for-pass-Marker Vary beachten: Varianten an derselben Cacheadresse können unterschiedlich behandelt werden.

Ein öffentliches Objekt und eine personenbezogene Antwort haben unterschiedliche Wiederverwendungsgrenzen. Ein äußerlich gleicher Pfad beweist nicht, dass beide an mehrere Nutzer ausgeliefert werden dürfen.

Ein unbrauchbares Ergebnis kann die Liste neu starten

Fastly dokumentiert einen schwierigen Zweig. Die Anfrage wurde gebündelt, doch die Antwort kann die wartenden Nutzer nicht bedienen, und ein Hit-for-pass-Marker kann nicht angelegt werden. Die nächste Anfrage geht zum Origin, die übrigen können dahinter eine neue Liste bilden.

Wiederholt sich dieser Zustand, erfolgen die Abrufe nacheinander statt gleichzeitig. Der Leitfaden warnt in manchen Situationen vor mehreren Minuten Wartezeit. Das ist eine veröffentlichte Möglichkeit, kein beobachteter Vorfall, keine Kontoprognose und kein zwangsläufiges Ergebnis jeder privaten Antwort.

Die VCL-Referenz nennt eine konkrete Bedingung. Bei beresp.cacheable gleich false werden weder das Objekt gespeichert noch ein Hit-for-pass-Objekt erstellt, selbst wenn die Verarbeitung mit deliver endet. Freigegebene Folgeanfragen können sofort wieder eine Warteschlange bilden.

Wenig Origin-Aktivität erhält hier zwei mögliche Bedeutungen. Entweder schließt geteilte Arbeit mehrere Aufgaben ab, oder Anforderungen sammeln sich ohne brauchbares Ergebnis. Der aggregierte Abrufzähler unterscheidet das nicht.

Die Lösung darf nicht darin bestehen, vertrauliche Inhalte kurzerhand wiederverwendbar zu machen. Dieselbe Referenz weist darauf hin, dass true sonst nicht cachefähige Antworten speichern lassen kann. Ein besserer Warteschlangenwert legitimiert keine veränderte Informationsgrenze.

Ein Marker speichert eine Behandlungsentscheidung

Hit-for-pass hält fest, dass Anfragen für die betroffene Ressource oder Variante nicht gebündelt werden sollen. Sie gehen stattdessen einzeln zum Origin. Ein Cacheeintrag muss deshalb nicht den Inhalt einer privaten Antwort enthalten.

Im dokumentierten CDN-VCL-Pfad, der das Durchreichen bei der Antwortverarbeitung entscheidet, kann ein geeigneter Verarbeitungszustand den Marker anlegen, ohne den Antwortkörper für wartende Nutzer wiederzuverwenden. Die Markierung und der Inhalt sind getrennte Belege.

Fastly unterscheidet außerdem das Durchreichen bereits auf Anfrageebene. Ist vor dem Abruf bekannt, dass Arbeit nicht wiederverwendbar sein wird, kann sie von Beginn an außerhalb des Collapsing bleiben. Der Zeitpunkt der Einordnung beeinflusst die Entstehung der Liste.

Diese Aussagen sind an Bedingungen und Schnittstellen gebunden. VCL-spezifische Kontrollen sind keine einheitliche Beschreibung sämtlicher Compute-Cacheinterfaces. Einzelne, möglicherweise parallele Origin-Anfragen beseitigen die Nachfrage auch nicht. Der Origin braucht Kapazität für diese Arbeit; ein anderer Zweig erzeugt sie nicht automatisch.

Flüchtige Wiederverwendung ist nicht dauerhafte Frische

Der Collapsing-Leitfaden beschreibt Antworten ohne private-Markierung, die bereits wartende Clients auch mit max-age=0 oder no-cache bedienen können. Die nächste Anfrage kann dennoch erneut einen Cachemiss auslösen.

In diesem Wartelistenkontext unterscheiden sich Wiederverwendung während des Abrufs und ein frisches gespeichertes Objekt für spätere Ankünfte. Daraus folgt weder eine allgemeine Gleichwertigkeit von HTTP-Direktiven noch die Erlaubnis, eine nutzerspezifische Antwort wegen einer Frischezeit von null zu teilen.

Dieser Fall ist auch nicht mit beresp.cacheable gleich false zu verwechseln. Datenschutz, Cachefähigkeit, Frische und Wartelistenverhalten sind unterschiedliche Eigenschaften.

Fastlys erläuternder Blog definiert eine Kennzahl für nutzbare Objekte über Cachefähigkeit und eine positive verbleibende Lebensdauer. Dieser Zähler darf nicht stillschweigend auf jeden andernorts beschriebenen Wartelistenfall übertragen werden. Die Definition gehört zum Wert.

Streaming Miss fügt eine Zeitbedingung hinzu. Wenn es aktiviert ist, können verwendbare Daten mit dem Eintreffen der Origin-Antwortheader in den Cache gelangen. Das Zeitfenster, in dem neue Anfragen den ersten Abruf überlappen, kann dadurch kürzer werden.

Weniger Collapsing kann also mit einem schnellen, effizient genutzten Origin zusammengehen. Die Häufigkeit allein belegt weder Erfolg noch Fehler und sagt nicht, dass jede Nutzeraufgabe abgeschlossen wurde.

Veraltete Antworten haben eine eigene Legitimität

Fastlys Tutorial beschreibt Bedingungen und Zeitfenster für die Auslieferung veralteter Inhalte, einschließlich bestimmter Origin-Probleme. Es verspricht nicht, dass jede Fehlermeldung automatisch eine alte Antwort ersetzt.

Auch folgt daraus nicht, dass alte Berechtigungen, Bestände oder Preise akzeptabel sind. Die Anwendung muss entscheiden, wann ein Ergebnis noch das erforderliche Ergebnis ist. Geschwindigkeit und Verfügbarkeit ersetzen diese Prüfung nicht.

Damit wird der anfängliche Kontrollpunkt verständlich. Wer Collapsing vermeidet, sollte sowohl die dadurch getrennte Origin-Arbeit als auch veränderte Möglichkeiten für alte Inhalte kennen. Eine Warteschlangenkontrolle lässt sich nicht allein anhand der verschwundenen Warteschlange abnehmen.

Nützliche Lieferung ist der Gegenstand der Abnahme

Ein kurzer Entscheidungsnachweis kann Inhaltsklasse, tatsächliche Cacheidentität und Varianten, erlaubte Wiederverwendung, Serviceschnittstelle, Fehlerzweig sowie zulässige Wartezeit und Frische festhalten. Das ist eine redaktionelle Empfehlung, keine Pflichtfunktion von Fastly oder ein Audit einer Kundenkonfiguration.

Danach lässt sich präzise fragen: Entstanden bei weniger Origin-Abrufen mehr abgeschlossene brauchbare Antworten mit akzeptablem Warten? Oder standen weitere Anforderungen hinter einem Ergebnis, das sie nicht bedienen konnte? Blieb getrennte Arbeit sicher getrennt, ohne einen untragbaren Ansturm zurückzuverlagern?

Keine Kundeneinsparung oder Laufzeitfolge wurde gemessen. Der begrenzte kommerzielle Schluss ist dennoch nützlich: Bündelung hat Wert, wenn geteilte Arbeit legitime Auslieferung abschließt. Die Entlastung ist ein Beleg für den Weg, nicht der Ersatz für das Ergebnis.

Quellen