Bei Kinsta sind wir besessen von Geschwindigkeit: Unsere Dienste für Anwendungs-Hosting, Datenbank-Hosting und Managed WordPress Hosting laufen alle auf dem schnellsten Premium Tier Network und den C2-Maschinen der Google Cloud Platform, und wir verlassen uns auf Cloudflare, damit Zehntausende von Kunden, die ihre Inhalte schnell und sicher in die ganze Welt liefern wollen, das Gaspedal durchtreten können.

Dabei haben wir einiges über die Verwendung von Cloudflare Workers und Workers KV gelernt, um optimierte Caching-Regeln für statische und dynamische Inhalte bereitzustellen.

Anfang 2023 haben wir die Cloudflare Cache-Verwaltung verdoppelt, so dass die Caches besser auf kundenseitige Konfigurationsänderungen reagieren und gleichzeitig die schwere Arbeit bei der Übertragung von Funktionsaktualisierungen von unseren Administratoren im Backend auf Cloudflare Workers verlagert wurde. Ein wichtiges Ergebnis war ein dramatischer Anstieg des Anteils der erfolgreich gecachten Kundendaten, der zwischen Oktober 2022 und März 2023 um 56,3 % zunahm.

Die Daten zeigen den Anstieg des Prozentsatzes der erfolgreichen Cache-Treffer im Laufe der Zeit.
Die Optimierung über Cloudflare Workers wurde im Januar 2023 stärker in den Fokus gerückt

Cloudflare Workers und Workers KV ermöglichen es uns, jede Anfrage und Antwort mit minimalem Aufwand und geringerer Latenz programmatisch anzupassen. Wenn wir neue Funktionen implementieren wollen, müssen wir die Änderungen nicht mehr in Hunderttausenden von Containern bereitstellen. Wir können die Funktion mit Workers replizieren oder implementieren und sie mit wenigen Befehlen und Klicks überall bereitstellen, was uns tagelange Arbeit und Wartung erspart.

Anfrage-Routing mit Workers KV und Workers

Jede von Kinsta gehostete Domain ist ein Schlüssel, dessen Wert zumindest die Grundeinstellungen wie die IP und den Port des Ursprungs sowie eine eindeutige Zufalls-ID enthält. Da diese Daten in Workers KV leicht verfügbar sind, können wir Workers verwenden, um Anfragen zu analysieren, zu bearbeiten und an das erwartete Backend weiterzuleiten. Wir nutzen Workers KV auch, um Optimierungsoptionen für Kunden zu speichern, wie z. B. Polieren, Bildgrößenanpassung und automatisches Verkleinern.

Um Anfragen an benutzerdefinierte IPs und Ports weiterzuleiten, verwenden wir resolveOverride, eine Cloudflare-spezifische Request-Eigenschaft. Hier ist ein Beispiel:

// Assign KV values to variables
const { customBackend } = kvdata.kinstaConf;

// Override the backend
cf.resolveOverride = customBackend;

Obwohl Workers KV gut funktionierte, um Anfragen weiterzuleiten, bemerkten wir bald uneinheitliche Antworten in unserem Cache. Manchmal aktivierte ein Kunde Polnisch, und aufgrund des einminütigen Caches von Workers KV trafen neue Anfragen ein, bevor Workers KV die Änderung vollständig übertragen hatte, was dazu führte, dass wir nicht optimierte Assets im Cache hatten. In diesem Fall musste der Kunde seinen Cache wieder manuell löschen. Kein ideales Szenario. Die Kunden waren frustriert, und wir verschwendeten API-Vorgänge und GCP-Bandbreite, weil wir ständig Caches leerten.

Der Cache-Schlüssel ist der Schlüssel

Da wir immer die KV-Daten der Domäne lesen, erkannten wir, dass wir Anfragen weiterleiten und den Cache-Schlüssel anpassen können, indem wir Dinge wie die ID der Domäne und Merkmale, die sich auf das Asset auswirken können, wie z. B. Polnisch, anhängen. Heute ist unser Cache-Schlüssel stark angepasst, um jede Änderung des Kunden in unserem Panel oder der API schnell zu berücksichtigen. Indem wir den Cache-Schlüssel mit den Daten von Workers KV ändern, muss sich niemand mehr um die Löschung des Caches kümmern. Sobald Workers KV die Änderungen weitergibt, ändert sich auch der Cache-Schlüssel, und wir fordern ein neues Asset an und speichern es im Cache.

Am einfachsten lässt sich der Cache-Schlüssel anpassen, indem du query params an ihn anhängst. Zum Beispiel:

let cacheKey = `${request.url}?custom-cache-param-polish=lossy`

Natürlich musst du die URL auf vorhandene Parameter überprüfen, um festzustellen, welchen Anschluss du verwenden sollst – ? oder & – und um sicherzustellen, dass du einen eindeutigen Bezeichner verwendest.

Dann kannst du diesen neuen Cache-Schlüssel verwenden, um die Antwort mit Cache-API oder Fetch – oder beidem – zu speichern.

Workers KV-Cache

Workers KV-Vorgänge sind erschwinglich, aber die Zahlen können sich stapeln, wenn du täglich Milliarden von Lesevorgängen auslöst.

Dank unserer Anpassung des Cache-Schlüssels haben wir festgestellt, dass wir die Workers KV-Daten mit der Cache-API zwischenspeichern können, wodurch wir Lesevorgänge einsparen und möglicherweise die Latenzzeit verringern können, indem wir mehrere Workers KV-GET-Anfragen pro Besucher vermeiden. Da die zwischengespeicherte Antwort nun auf der URL der Anfrage in Kombination mit den KV-Daten basiert, müssen wir uns keine Sorgen mehr über das Zwischenspeichern veralteter Inhalte machen.

Der Prozessablauf mit der Zwischenspeicherung von Workers KV-Daten
Der Prozessablauf mit der Zwischenspeicherung von Workers KV-Daten
Durchschnittliche Zeit bis zum ersten Byte in verschiedenen Caching-Szenarien
Durchschnittliche Zeit bis zum ersten Byte in verschiedenen Caching-Szenarien

Im Gegensatz zu vielen anderen Anwendungen können wir Workers KV jedoch nicht über längere Zeiträume zwischenspeichern. Die Kunden von Kinsta probieren ständig neue Funktionen aus, ändern die Einstellungen für Polnisch und Auto Minify und schließen manchmal Seiten oder Erweiterungen vom Caching aus.

Deshalb haben wir uns entschieden, unsere Workers KV-Daten im Microcache zu speichern. Dynamische oder sich ständig ändernde Inhalte werden für einen sehr kurzen Zeitraum zwischengespeichert, in der Regel für weniger als 60 Sekunden.

Es ist ziemlich einfach, deine eigene Workers KV-Caching-Logik zu implementieren. Ein Beispiel:

const handleKVCache = async (event, myCustomDomain) => {
  // Try to get KV from cache first
  const cache = caches.default;
  let site_data = await cache.match( `https://${myCustomDomain}/some-string-ID-kv-data/` );

  // Valid KV cache match
  if (site_data && site_data.status === 200) {
    // ... modify your cached data if necessary, then return it
    return site_data;
  }

  // Invalid cache (expired, miss, etc), get data from KV namespace
  site_data = await KV_NAMESPACE.get(myCustomDomain.toLowerCase());
  
  // Cache valid KV responses with Cache API
  if (site_data) {
    let kvResponse = new Response(JSON.stringify(site_data), {status: 200});
    kvResponse.headers.set("Cache-Control", "public, s-maxage=30");
    event.waitUntil(cache.put(`https://${myCustomDomain}/some-string-ID-kv-data/`, kvResponse));
  }
  
  return site_data;
};

(Optional könntest du FlareUtils‘ BetterKV verwenden.)

Bei Kinsta haben wir eine Cache-TTL von 30 Sekunden für Workers KV-Daten eingeführt, wodurch die Lesevorgänge um etwa 80 % reduziert wurden.

Die Grafik zeigt die Entwicklung der Lesevorgänge im Laufe der Zeit.
Rückgang der Lesevorgänge nach Einführung einer TTL von 30 Sekunden für den Workers KV-Datencache

Mehr erfahren

Möchtest du mehr über Workers und Workers KV erfahren? Schau dir die Cloudflare Workers KV-Entwicklerdokumentation an oder besuche die spezielle Workers KV-Homepage von Cloudflare.

Dieser Artikel wurde ursprünglich auf der Cloudflare-Website veröffentlicht.

Paulo Paracatu

Paulo ist ein erfahrener DevOps-Ingenieur bei Kinsta mit einem soliden Hintergrund im Bereich Webhosting und -optimierung. Ausgestattet mit Bash- und JavaScript-Kenntnissen nutzt er Cloudflare Workers, um die Benutzererfahrung beim Hosting kontinuierlich zu verbessern.