Cloudflare testet eine Methode, um die effektive Kapazität seines Caching-Netzwerks zu erhöhen, ohne neue Hardware hinzuzufügen: Einige Text-Assets werden mithilfe des Zstandard-Algorithmus innerhalb der auf Pingora basierenden Infrastruktur komprimiert. Der von dem Unternehmen Cache Transcoding genannte Prototyp soll den von Daten auf Datenträgern belegten Speicherplatz sowie die zwischen Cache-Schichten und Rechenzentren übertragenen Datenmengen reduzieren.
Wenn eine geeignete Antwort in den Cache gelangt, werden ihre Daten mithilfe von zstd in eine komprimierte Darstellung umgewandelt, bevor sie auf den Datenträger geschrieben werden. Die Assets bleiben in dieser Form, solange sie sich im Cache befinden und während ihrer Übertragung über den Tiered Cache; erst vor der Übermittlung an den Client werden sie dekomprimiert. Der Dateiinhalt selbst ändert sich dadurch nicht, denn Zstandard ist ein verlustfreier Kompressionsalgorithmus, der nach der Dekomprimierung jedes Byte in seinen ursprünglichen Zustand zurückführt.
Großes Ergebnis bei begrenzten Verarbeitungskosten
In den ersten Tests sank die Größe der geeigneten Assets auf dem Datenträger im Durchschnitt auf etwa ein Drittel ihrer ursprünglichen Größe. In der kontrollierten Testgruppe lag das Kompressionsverhältnis bei 2,834. Die Kosten der Kodierung betrugen 4,31 Nanosekunden pro Byte beziehungsweise etwa 232 Megabyte pro Sekunde und fielen einmalig beim Befüllen des Caches an. Die Kosten der Dekomprimierung beliefen sich dagegen auf 1,56 Nanosekunden pro Byte beziehungsweise etwa 641 Megabyte pro Sekunde und fielen bei jeder Auslieferung an.
Das Experiment verwendet die dritte Stufe von Zstandard, da sie einen Ausgleich zwischen Ausführungsgeschwindigkeit und Ausgabegröße darstellt. Nach dem Modell von Cloudflare blieb der zusätzliche Prozessorverbrauch unter den vom Unternehmen getesteten Annahmen zu Datenverkehr und Wiederverwendung bei wenigen Prozent. Durch die Verringerung der Datenmenge kann jeder Server außerdem mehr Elemente vorhalten; dadurch sinkt die Wahrscheinlichkeit, dass nützliche Inhalte wegen eines unnötig hohen Speicherbedarfs aus dem Cache verdrängt werden.
Warum komprimiert Cloudflare nicht alles?
Die Methode zielt nicht auf alle Inhaltstypen ab. Bilder, Videos und Schriftarten sind in der Regel bereits komprimiert. In der Datenverkehrsstichprobe machten sie 21,4 % der Anfragen, aber 63,3 % der gesamten Bytezahl aus. Eine erneute Komprimierung dieser Daten könnte Prozessorleistung verbrauchen, ohne nennenswerte Einsparungen zu bringen.
HTML, JSON, CSS und JavaScript machten dagegen etwa 67,3 % der Anfragen und 22,3 % der Bytes aus. Rund 71 % dieser Textantworten kamen ohne Content-Encoding vom Ursprung, wodurch sie für eine Komprimierung infrage kamen. Der Prototyp ist auf 200-OK-Antworten beschränkt, die kein Content-Encoding angeben, einen komprimierbaren Textinhaltstyp besitzen und eine bekannte Länge von mindestens 4 KiB aufweisen.
Teilbereichsanfragen, vom Ursprung bereits komprimierte Antworten, Range-Anfragen, Objekte mit unbekannter Länge und binäre Inhalte bleiben unverändert. Cloudflare stellte fest, dass die Grenze von 4 KiB eine große Zahl kleiner Anfragen ausschließt, jedoch nur etwa 1 % der Bytes entfernt, die ansonsten geeignet gewesen wären.
Wie funktioniert die Methode über die Cache-Schichten hinweg?
Bei einem vollständigen Cache-Miss ruft die obere Ebene die unkomprimierten Daten vom Ursprung ab, komprimiert sie einmal und speichert sie im zstd-Format. Dieses komprimierte Format wird an die untere Ebene übertragen, die es vorhält und nur auf dem zum Client führenden Anfragepfad dekomprimiert. Befindet sich das Element nur in der oberen Ebene, kann es in die untere Ebene verschoben werden, ohne erneut auf den Ursprung zuzugreifen.
Ist das Element dagegen in der unteren Ebene vorhanden, sind weder eine neue Netzwerkübertragung noch eine erneute Kodierung erforderlich: Die zstd-Daten werden vom Datenträger gelesen, dekomprimiert und anschließend an den Antwortpfad weitergeleitet. Das System vermerkt in seinen Metadaten, dass das Element in komprimierter Form gespeichert ist, um eine erneute Komprimierung beim Übergang zwischen den Cache-Schichten zu verhindern.
certi.news-Lesart: Was weist das Experiment tatsächlich nach?
Das Experiment zeigt, dass die Verringerung der Datenmenge innerhalb der Speicherschicht selbst kumulativ größere Auswirkungen haben kann als die alleinige Optimierung des Befüllens des Caches. Die Kosten der Komprimierung fallen beim Eingang des Elements an, während sich die Einsparungen bei Speicherplatz und Bandbreite bei jeder erneuten Nutzung wiederholen. Das ist insbesondere für Betreiber großflächiger Verteilungsnetze relevant, da die lokale Kapazität mit der Menge der vorhaltbaren Inhalte zusammenhängt und die Datenübertragung zwischen den Schichten interne Netzwerkressourcen verbraucht.
Die Ergebnisse bedeuten jedoch nicht, dass das Verhältnis von 2,8 für sämtliche Internetinhalte oder die gesamte Cloudflare-Infrastruktur repräsentativ ist. Der Leistungstest stützte sich auf mehr als eine Million Anfragen über zehn Cache-Server, verwendete jedoch ein experimentelles Ursprungsszenario mit zwei Elementen von etwa 195 beziehungsweise 272 KiB Größe, die deutlich komprimierbar waren. Das Unternehmen räumt ein, dass eine breitere Auswahl an Inhaltstypen und Größen erforderlich ist, bevor das Verhältnis als repräsentativ für die gesamte Flotte gelten kann.
Cloudflare plant, höhere zstd-Stufen zu testen, den Umfang der Inhalte und Größen zu erweitern, die Eignungsbedingungen anzupassen sowie Range-Anfragen und bereits komprimierte Antworten zu untersuchen. Daher bleibt Cache Transcoding im vorliegenden Beitrag ein unter bestimmten Bedingungen erfolgreicher Prototyp und ist keine Ankündigung einer endgültigen Einführung für den gesamten Cloudflare-Datenverkehr.