Zusammenfassung

  • Mit Workers Cache werden Anfragen an den betreffenden Worker zum Standardtarif gezählt, einschließlich sonst kostenloser statischer Dateien. Ein Cachetreffer vermeidet die Codeausführung und deren CPU-Gebühr, die Anfrage bleibt im Zähler.
  • Das rechenintensive offizielle Beispiel spart 11,20 Dollar. Auf ein anderes Beispiel mit hohem statischem Anteil angewandt, ergeben die Regeln dagegen 1,50 Dollar Mehrkosten bei vollständig verfügbaren Monatskontingenten.

Der Prozessor bekommt frei. Der Gebührenzähler bekommt Kundschaft.

Workers Cache sucht nach einer gespeicherten Antwort, bevor der Worker seinen Code ausführt. Bei einem Treffer wird die Antwort direkt ausgeliefert. Wiederholte Rechenarbeit entfällt. Gleichzeitig werden mit eingeschalteter Funktion alle Anfragen an diesen Worker nach dem Standardtarif für Anfragen berechnet. Dazu gehören statische Dateien, deren Abruf gewöhnlich kostenlos ist.

Cloudflare beschreibt die Funktion als ohne gesonderten Preis und nennt ausdrücklich den erweiterten Kreis abrechenbarer Anfragen. Beides passt zusammen. Ein Anbieter braucht keine neue Preiszeile, wenn mehr Nutzung in eine vorhandene fällt. Deshalb gehört der Geltungsbereich des Schalters in die Einkaufsentscheidung.

Wie zum Fünf-Dollar-Beispiel 1,50 Dollar hinzukommen

Workers Paid Standard kostet mindestens 5 Dollar im Monat je Konto. Enthalten sind 10 Millionen Anfragen und 30 Millionen CPU-Millisekunden. Darüber kosten eine Million Anfragen 0,30 Dollar und eine Million CPU-Millisekunden 0,02 Dollar. Die Kontingente gelten für das Konto; jeder zusätzliche Worker erhält kein neues Paket.

Beispiel 2 auf der offiziellen Preisseite verarbeitet monatlich 15 Millionen Anfragen. Zwölf Millionen liefern statische Dateien, drei Millionen führen dynamischen Code mit durchschnittlich sieben CPU-Millisekunden aus. Die statischen Abrufe sind kostenlos. Dynamische Anfragen und ihre 21 Millionen CPU-Millisekunden bleiben innerhalb der Kontingente. Die veröffentlichte Summe beträgt 5 Dollar.

Nun bleibt der Datenverkehr gleich, aber Workers Cache wird für den gesamten Worker eingeschaltet. Diese Rechnung setzt ein bezahltes Standardkonto mit vollständig verfügbaren Monatskontingenten voraus, ohne weitere Nutzung, Produkte sowie Steuer- oder Rabattkorrekturen. Jetzt zählen alle 15 Millionen Anfragen. Die fünf Millionen über dem Kontingent kosten 1,50 Dollar.

Selbst ohne einen einzigen Cachetreffer bei den dynamischen Antworten bleiben 21 Millionen CPU-Millisekunden unter den enthaltenen 30 Millionen. Die CPU-Zusatzgebühr bleibt null. Weitere Einsparungen können diese Gebühr nicht unter null drücken. Insgesamt entstehen 6,50 Dollar.

Das ist eine eigene bedingte Berechnung aus veröffentlichten Regeln und den Mengen von Beispiel 2. Cloudflare weist diese Summe nicht als beobachtete Kundenrechnung aus. Der Mechanismus ist konkret: Bereits enthaltene Rechenzeit zu sparen, bezahlt nicht automatisch neu berechnete Anfragen.

Wer CPU bezahlt, kann CPU-Gebühren sparen

Ein anderes offizielles Beispiel zeigt einen klaren finanziellen Vorteil. Hundert Millionen monatliche Anfragen mit durchschnittlich sieben CPU-Millisekunden ergeben 5 Dollar Grundpreis, 27 Dollar für zusätzliche Anfragen und 13,40 Dollar für CPU. Summe: 45,40 Dollar.

Bei 80 Prozent Cachetreffern führen nur noch 20 Millionen Anfragen Code aus. Die CPU-Nutzung sinkt auf 140 Millionen Millisekunden, die entsprechende Zusatzgebühr auf 2,20 Dollar. Die Anfragen kosten weiter 27 Dollar. Gesamtbetrag: 34,20 Dollar.

Die Ersparnis beträgt 11,20 Dollar, ungefähr ein Viertel der ganzen Rechnung. Die Trefferquote von 80 Prozent misst Antworten ohne Codeausführung. Die Rechnung enthält weiterhin die Auslieferung von Anfragen. Außerdem verändert das enthaltene CPU-Kontingent das Verhältnis zwischen gesparter Rechenzeit und gesparten Dollar.

Ein dynamischer Dienst mit hoher CPU-Rechnung bietet dem Cache eine bestehende Ausgabe zum Kürzen. Ein überwiegend statischer Dienst, dessen dynamische Arbeit ohnehin im Kontingent liegt, kann zuerst auf den erweiterten Kreis kostenpflichtiger Anfragen treffen. Derselbe Schalter hat je nach Ausgangslage eine andere Wirtschaftlichkeit.

Welcher Worker den Schalter bekommt

Gemeint ist die konkrete Funktion Workers Cache vor der Codeausführung. Sie hat einen anderen Geltungsbereich als die ältere Cache API innerhalb des Codes und gewöhnliches zonenbezogenes CDN-Caching. Laut Dokumentation wird sie nicht durch Cache Rules oder Page Rules einer Zone eingerichtet.

Die Abrechnung umfasst auch Worker-zu-Worker-Aufrufe, die bei gewöhnlichen Standard-Service-Bindings keine zusätzliche Anfragegebühr auslösen. Bei einer in mehrere Worker zerlegten Anwendung wird die Auswahl des Workers mit aktivierter Funktion damit Teil der Kostenarchitektur. Eine genaue Kettenrechnung braucht den tatsächlichen Pfad und seine Einstellungen; die Zahl der Bausteine allein reicht nicht.

Mehrstufiges Caching und das Zusammenfassen gleichzeitiger Anfragen können weitere Ausführungen vermeiden. Ausgelieferte Anfragen behalten ihren eigenen Zähler. Die Plattform verkauft auch die Zustellung einer Antwort, wenn deren Berechnung leichter geworden ist.

Für eine echte Rechnung fehlen die Verkehrsarten, der CPU-Verbrauch, bereits von anderen Aufgaben verbrauchte Kontingente und die Vertragsbedingungen. Diese Zahlen entscheiden, welcher Effekt überwiegt.

Nach „Die Trefferquote ist gestiegen“ braucht die Einkaufsrunde eine Anschlussfrage: Welche bisher kostenlosen Anfragen stehen jetzt auf der Rechnung? Der Prozessor darf Pause machen. Für den Einkauf ist die Rechenstunde noch nicht vorbei.

Quellen