So lügt man mit (Cloudflare) Statistik – Wir entlarven Cloudflares jüngste Performance-Tests

Wie schon Mark Twain wusste, gibt es drei Arten von Unwahrheiten: Lügen, infame Lügen und Statistiken. Das ist vielleicht etwas übertrieben, denn einige Statistiken sind wirklich solide, aber diese hier mit Sicherheit nicht:

Worauf sollen wir zuerst eingehen? Die Art und Weise, in der Catchpoint in diesem Zusammenhang zitiert wird, lässt den Leser vermuten, es handle sich bei der Aussage um die unabhängige Studie eines Drittanbieters. Dem ist nicht so. Catchpoint ermöglicht es Ihnen, die plattformeigenen Tools auf Ihre Anforderungen abzustimmen, was bedeutet, dass Sie sie zur Durchführung eines auf einem fairen und strengen Benchmark-Standard basierenden Tests nutzen können – oder aber eines frei erdachten Tests, der die Wahrheit so hindreht, wie Sie sie gerne hätten.

Was also ist an Cloudflares Tests falsch?

Konzeption und Ausführung von Cloudflares Tests waren in vielerlei Hinsicht fehlerhaft: 

1. Cloudflare hat bei seiner Untersuchung auf eine kuratierte Auswahl von Catchpoint Edge-Knoten zurückgegriffen. Es wird nicht erklärt, warum gerade diese Knoten ausgewählt wurden. Allerdings sollte an dieser Stelle erwähnt werden, dass die Standorte von Cloudflares Infrastruktur von den unseren leicht abweichen, und eine voreingenommene Auswahl der Teststandorte beeinflusst das Testergebnis erheblich.

2. Bei den Tests wird das auf Cloudflare Workers, einem ausgereiften, weithin verfügbaren Produkt, ausgeführte JavaScript mit dem auf Compute@Edge ausgeführten JavaScript verglichen. Obwohl die Compute@Edge Plattform jetzt für alle in der Produktivumgebung verfügbar ist, steckt der Support für das auf Compute@Edge ausgeführte JavaScript noch immer in der Betaversion. In unserer Dokumentation geben wir klipp und klar an, dass Betaprodukte nicht für den Einsatz in der Produktivumgebung empfohlen werden. Ein sachgemäßerer Test hätte also lauten sollen, JavaScript auf Cloudflare Workers mit Rust auf Compute@Edge zu vergleichen, da sich beide in vergleichbareren Phasen des Produktlebenszyklus befinden.

3. Cloudflare hat bei seiner Untersuchung eine kostenlose Fastly Testversion genutzt. Kostenlose Testversionen sind im Vergleich zu kostenpflichtigen Fastly Konten für eine eingeschränkte Nutzung ausgelegt, und die Leistungsfähigkeit lässt sich nicht 1:1 miteinander vergleichen.

4. Der von Cloudflare festgesetzte Testzeitrahmen betrug eine einzige Stunde, an einem einzigen Tag. Tägliche Traffic-Muster oder außergewöhnliche Ereignisse können in einer so kurzen Spanne unmöglich berücksichtigt werden, weshalb die Wahrscheinlichkeit von willkürlichen Verzerrungseffekten groß ist. Wenn man wiederholt Testreihen zu unterschiedlichen Tageszeiten durchführen würde, würde man sehr wahrscheinlich irgendwann das gewünschte Ergebnis erzielen.

5. Im Blogpost wird erwähnt, dass man über den Testcode „eine Funktion ausgeführt hätte, die die aktuelle Zeit automatisch wiedergeben würde“, allerdings wird dann ein Codebeispiel angeführt, das eine Kopie des Headers der eingehenden Anfrage wiedergibt. Hier liegt also irgendwo ein Fehler vor. Es ist nicht möglich, ein Testergebnis objektiv zu bewerten oder gar zu reproduzieren, wenn die Testmethodik zuvor nicht klar definiert wurde.

6. Die Time to First Byte (TTFB) ausschließlich anhand von Tests zu bewerten, bei denen so gut wie kein Berechnungsaufwand, keine wesentlichen Payloads und keine Plattform-APIs anfallen, stellt keine repräsentative Messung der Performance von Compute@Edge dar.

Die Cloudflare Statistiken sind nicht aussagekräftig. Warum also lenken wir Ihr Augenmerk darauf und wie steht es denn ganz nebenbei um die Performance von Compute@Edge wirklich?

Überraschung! Compute@Edge ist schneller als Cloudflare Workers

Zugegebenermaßen können wir das nicht mit hundertprozentiger Sicherheit sagen, weil die Kennzahl TTFB nichts Handfestes darüber aussagt, welche Plattform „schneller“ ist (mehr dazu gleich). Aber wir können mit großer Sicherheit sagen, dass unser Netzwerk und Compute@Edge in einer weniger verzerrten Version des gleichen Tests besser abschneiden als Cloudflares Netzwerk und Cloudflare Workers, auch hinsichtlich der TTFB.

Es ist schwierig, die relative Performance von Edge-Netzwerken zu messen. Wir bewegen uns nicht mehr im Zeitalter von CDNs. Heutzutage lässt sich der Wert eines Edge-Netzwerks nicht anhand einer einzigen Variablen bestimmen. Insbesondere Cloudflare sollte das wissen, denn das Tech-Unternehmen verfügt über eine ansehnliche Reihe von Funktionen auf der Edge – von denen im Übrigen keine in dieser Untersuchung Anwendung fanden.

Wir wollen in unseren vergleichenden Tests den fragwürdigen Benchmark nicht übernehmen und sehen uns gleichzeitig außer Stande, unsere eigenen Anforderungen für den Vergleich festzulegen, da Cloudflares Geschäftsbedingungen das Benchmarking seiner Services untersagen:

Wir haben also den gleichen Test (Messung der TTFB via Catchpoint und Kopie der Header) an unserer eigenen Plattform durchgeführt, dabei jedoch ein paar wesentliche Veränderungen vorgenommen:

• Wir haben in unseren Messungen auf 673 Catchpoint Knoten anstatt 50 zurückgegriffen, und zwar über einen sehr viel längeren Zeitraum (eine Woche anstatt eine Stunde).

• Wir haben ein aus Rust und nicht JavaScript kompiliertes Wasm Binärprogramm genutzt. 

• Wir haben ein kostenpflichtiges Fastly Konto anstatt einer kostenlosen Testversion verwendet.  

Sie können sich die Rohdaten der sachgemäßeren Tests hier ansehen. Die Quintessenz ist, dass unser Netzwerk und Compute@Edge in vier von sechs Bereichen schneller als Cloudflares Netzwerk und Cloudflare Workers sind, selbst bei der Messungder nicht repräsentativen Kennzahl TTFB:

Fastly Daten: Median TTFB, 673 Catchpoint Nodes, 378.000 Requests, durchgeführt zwischen 00:00 Uhr am 24.11.2021 und 00:00 Uhr am 30.11.2021 (6 Tage) [Testergebnisse] Cloudflare Data: Median TTFB, 50 Catchpoint Nodes, unbekannte Anzahl an Requests, durchgeführt zwischen 20:30 Uhr und 22:00 Uhr am 8.11.2021 (1,5 Stunden) [Testergebnisse]

Wenn man die beiden Unternehmen auf Grundlage ihrer Performance hinsichtlich der TTFB vergleicht, erkennt man, dass unser auf Compute@Edge ausgeführtes Netzwerk in Nordamerika und Europa fast doppelt so schnell und in Ozeanien zehnmal schneller als das von Cloudflare Workers ist. Laut Cloudflares Geschäftsbedingungen ist Benchmarking wie gesagt verboten, was bedeutet, dass wir den Anbieter nicht direkt testen und so auch die auffälligen Daten für Ozeanien nicht nachstellen können.

Compute@Edge liegt keine native Sprache zugrunde, da wir WebAssembly Binärprogramme direkt auf unseren Edge-Servern ausführen, aber Rust ist aktuell die Sprache, in der kompilierter Code gut funktioniert UND die für Entwickler benutzerfreundlich ist. Sie können selbstverständlich alles auf Compute@Edge ausführen, was sich nach WebAssembly kompilieren lässt – und Entwickler tun das auch.

Ja, aber … was ist mit JavaScript?

Wir wissen, dass der Support für JavaScript vielen Kunden sehr wichtig ist, aber wir sind mit der Leistung von Compute@Edge Paketen, die aus JavaScript kompiliert werden, noch nicht hundertprozentig zufrieden. Deshalb befinden sie sich ja in der Betaversion. Wenn ein Produkt für die Liveumgebung freigegeben wird, entfernen wir die Betakennzeichnung.

Der Leitgedanke bei der Erstellung unserer außergewöhnlichen Edge-Computing-Plattform war von Anfang an, uns von den verfügbaren Produkten anderer Anbieter zu unterscheiden. Das heißt im Umkehrschluss auch, dass sich unsere Performance anders entwickelt, denn unser Ausgangspunkt ist ein anderer.

Die richtigen Kennzahlen messen

Lassen Sie uns die Kennzahl TTFB genauer betrachten und untersuchen, warum sie im gegebenen Zusammenhang nicht zielführend ist.

Die von Cloudflare veröffentlichten Testergebnisse stellen keine repräsentative Messung der Rechenleistung dar. Anstatt nur eine einzige Variable zu messen, sollten wir einen Benchmark-Standard festlegen, anhand dessen sich die Performance von Edge Computing in zentralen Anwendungsfällen, wie sie auch von unseren Kunden genutzt werden, bewerten lässt. Dazu sollten neben der Netzwerk-Paketumlaufzeit auch folgende Variablen gehören:

• die für die Übergabe eines Requests an Kundencode benötigte Anlaufzeit

• die für Workloads unterschiedlicher Größen benötigte Rechenleistung („Denkzeit“)

• die Cache-Performance für sowohl Liveobjekte als auch Long-Tail-Inhalte

• die für Anwendungsfälle, bei denen Inhalte vom Origin-Server abgefragt werden, benötigte Paketumlaufzeit

Cloudflares Tests sind selbst bei der Messung von Netzwerk-Paketumlaufzeit unsachgemäß, weil die TTFB sowohl die Netzwerk-Paketumlaufzeit als auch die Denkzeit des Servers berücksichtigt. Es gibt in der Branche keine Möglichkeit nachzuvollziehen, wie die einzelnen Komponenten das Gesamtergebnis beeinflussen. Möchte man die Performance genauer analysieren, würde man die beiden trennen.  

Sehen Sie sich beispielsweise die folgende Grafik an, die Mittelwerte für Netzwerk-Paketumlaufzeit und TTFB für einen Fastly Service in Asien wiedergibt. Ein Cache Hit, der von unserer VCL-Plattform ausgeliefert wurde (linke Grafik), ist so schnell, dass sich der Graph für die Netzwerk-Paketumlaufzeit (blau dargestellt) mit dem für die TTFB (grün dargestellt) letztlich deckt. Unter Einsatz von Compute@Edge (rechte Grafik) hebt sich der Graph für die TTFB deutlich ab, was die erhöhten Kosten für die Ausführung von beliebigem Code widerspiegelt, während der Graph für die Paketumlaufzeit in Regionen mit allgemein höherer Verbindungslatenz (beispielsweise Asien wie in der untenstehenden Grafik) den Großteil des Wertes einnimmt.

Die Paketumlaufzeit kann je nach Standort stark variieren, wie sich an den Ergebnissen des Haupttests, den wir oben vorgestellt haben, deutlich ablesen lässt. Was man in den von Cloudflare durchgeführten Tests infolgedessen nicht erkennen kann, ist eine klare Abzeichnung der relativen Performance unserer Edge-Compute-Plattformen, also der „Denkzeit“ des Servers.

Bessere Ergebnisse für Kunden erzielen

Wir arbeiten derzeit an einer Benchmark-Suite, die sachgemäßere Rahmenbedingungen für die Bewertung der Performance stellen wird, und wir werden den Code für diese Benchmark-Suite öffentlich zugänglich machen und die von einer unabhängigen Drittpartei gemessenen Ergebnisse auch veröffentlichen. Einfach, weil wir infame Konkurrenzkämpfe, die davon ablenken, das Internet für alle Nutzer besser zu machen, unglaublich ermüdend finden.

Seien Sie bis dahin versichert, dass es absolut nicht der Wahrheit entspricht, dass Cloudflare Workers 196 % schneller ist als Compute@Edge – tatsächlich ist diese Plattform überhaupt nicht schneller. Die für unsere Kunden wichtigen Variablen sind die, die für ihr Geschäft entscheidend sind. Wenn Sie also wissen möchten, ob wir bei den für Ihre Bedürfnisse relevanten Kennzahlen schnell genug sind, laden wir Sie ein, den Fastly Service kostenlos zu testen und sich von unserer Performance selbst zu überzeugen.

Dieser Artikel enthält „zukunftsgerichtete Aussagen“, die auf Fastlys Einschätzungen und Annahmen sowie auf Fastly zum Zeitpunkt der Veröffentlichung dieses Artikels zur Verfügung stehenden Informationen beruhen. Zukunftsgerichtete Aussagen können bekannte und unbekannte Risiken, Ungewissheiten und andere Faktoren beinhalten, die dazu führen können, dass die von uns erzielten tatsächlichen Ergebnisse, Leistungen oder Erfolge wesentlich von dem abweichen, was in den zukunftsgerichteten Aussagen ausgedrückt oder impliziert wurde. Diese Aussagen beziehen sich unter anderem auf Aussagen betreffend zukünftige Produktangebote. Sofern nicht gesetzlich vorgeschrieben, übernimmt Fastly keine Verpflichtung, diese zukunftsgerichteten Aussagen oder die Gründe, aus denen die tatsächlichen Ergebnisse wesentlich von den in den zukunftsgerichteten Aussagen abweichen könnten, öffentlich zu aktualisieren, selbst wenn in Zukunft neue Informationen verfügbar werden. Wichtige Faktoren, die dazu führen könnten, dass Fastlys tatsächliche Ergebnisse wesentlich von den Aussagen abweichen, werden von Zeit zu Zeit in den Berichten beschrieben, die Fastly bei der Securities and Exchange Commission (SEC) einreicht. Außerdem werden sie in unserem Jahresbericht im Formblatt 10-K für das am 31. Dezember 2020 endende Geschäftsjahr und in unseren Quartalsberichten im Formblatt 10-Q aufgeführt. Kopien der bei der SEC eingereichten Berichte sind auf der Fastly Website veröffentlicht und können kostenlos bei Fastly angefordert werden.