- Im Benchmark des unabhängigen Entwicklers Theo Browne zeigte Cloudflare Workers eine bis zu 3,5-fach langsamere Leistung als Vercel Node.js
- Die Ursachen der Benchmark-Ergebnisse lagen in mehreren Problemen bei Infrastruktur-, Bibliothekskonfigurationen und der Benchmark-Methodik
- Es wurden zahlreiche Verbesserungen an Plattform und Framework vorgenommen, darunter Optimierungen am Scheduling-Algorithmus, Tuning des V8-Garbage-Collectors und OpenNext-Optimierungen
- Durch wichtige Patches hat sich der Leistungsunterschied zwischen Cloudflare und Vercel in den meisten Benchmarks inzwischen deutlich verringert
- Cloudflare will auch künftig zu offener Infrastruktur und Framework-Verbesserungen beitragen und fortlaufende Optimierungen sowie Benchmark-Validierungen fortsetzen
Überblick und Benchmark-Kontroverse
- Im Oktober 2023 veröffentlichte der Entwickler Theo Browne einen Benchmark zum Vergleich der serverseitigen JavaScript-Ausführungsgeschwindigkeit von Cloudflare Workers und Vercel (auf Basis von AWS Lambda)
- Cloudflare Workers basiert wie Vercel auf der V8-JavaScript-Engine, dennoch wurde ein Leistungsabfall von bis zu 3,5-fach beobachtet
- Ein unplausibler Leistungsabstand entstand durch verschiedene Faktoren wie Feinabstimmung der Infrastruktur, Unterschiede bei JavaScript-Bibliotheken und Probleme in der Testmethode
- Im Zuge der Behebung dieser Probleme verbesserte sich die Gesamtleistung von Cloudflare Workers
- Zu den wichtigsten Änderungen gehörten auch Verbesserungen wie eine schnellere Ausführung trigonometrischer Berechnungen, die Auswirkungen auf andere Plattformen haben können
Benchmark-Methodik
- Theos ursprünglicher Test-Client griff von San Francisco über Webpass zu, Vercel lief in der Region sfo1
- Bei Cloudflare wurde der Einfluss der Netzwerklatenz minimiert, indem innerhalb des AWS-Rechenzentrums us-east-1 direkt mit der iad1-Instanz von Vercel kommuniziert wurde
- Alle Benchmarks wurden in einer Single-Thread-Umgebung (1 vCPU) durchgeführt, wodurch auch Preisvergleiche leichter anzugleichen waren
- Während der Tests entdeckte Bugs wurden als Pull Requests Upstream eingereicht und behoben
Leistungsverbesserungen der Cloudflare-Plattform
Verbesserungen beim Scheduling und der Isolation in der Workers Runtime
- Bisher wurde ein Algorithmus verwendet, der Traffic an „warme“ Isolates (Instanzen, die schnell verarbeiten können) weiterleitet, um Latenz und Durchsatz großer Apps zu optimieren, was jedoch für CPU-intensive Workloads ineffizient war
- Wenn sich Anfragen mit hoher CPU-Auslastung häuften, wurden Warteschlangen länger und die Latenz stieg, was sich im Benchmark zeigte
- Bei Cloudflare Workers basiert die Abrechnung auf der CPU-Nutzungszeit, daher wird Wartezeit (Warten auf die Bereitstellung eines Isolates) nicht berechnet
- Durch eine Überarbeitung des Algorithmus werden Workloads mit hoher CPU-Last schneller erkannt und neue Isolates zügiger erzeugt
- Damit kann sowohl auf I/O-bound- als auch auf CPU-bound-Workloads effizient reagiert werden; die Änderung wurde weltweit ausgerollt und wirkte sofort
Verbesserungen an den Einstellungen des V8-Garbage-Collectors
- Im Testverlauf zeigte sich, dass Probleme bei der JavaScript-Garbage Collection und Speicherverwaltung erheblich zur Leistungsverschlechterung beitrugen
- Die Größe des „young generation“-Speicherbereichs in der V8-Engine war zu restriktiv fest eingestellt (an den früheren Richtwert von 128 MB angepasst)
- In aktuellem V8 führt diese Konfiguration eher zu unnötig häufigen GC-Läufen
- Das manuelle Tuning wurde deaktiviert, sodass die heuristikbasierte dynamische Speicherzuweisung von V8 selbst greifen kann
- Dadurch wurde eine Benchmark-Leistungssteigerung von etwa 25 % festgestellt und auf alle Workers angewendet
Performance-Optimierung von Next.js auf Basis von OpenNext
Entfernen unnötiger Speicherallokationen und Kopien
- Die Analyse zeigte, dass 10–25 % der Request-Verarbeitungszeit für Speicherfreigabe (GC) aufgewendet wurden
- In OpenNext, Next.js und React gab es viele Code-Muster, die interne Datenpuffer übermäßig kopierten
- Dazu gehörten unnötige Kopien kompletter Stream-Ausgabedaten sowie umfangreiche Datenkopien mit
Buffer.concat nur zur einfachen Längenbestimmung
- Die entsprechenden Probleme werden durch Pull Requests im OpenNext-Repository verbessert
- Weitere Optimierungen sind geplant, damit sich die Performance plattformübergreifend verbessern kann
Optimierung ineffizienter Stream-Adapter
- Workers setzt auf die Web Streams API, während Next.js hauptsächlich auf der Stream-API von Node.js basiert, sodass Konvertierungsadapter nötig sind
- Durch unnötig verschachtelte Adapter entstanden mehrfach Speicherkopien und Buffering-Overhead
- Der Code wurde vereinfacht auf
ReadableStream.from(chunks), wodurch Zwischenkopien entfernt wurden
- Die standardmäßige Struktur mit Single-Value-Streams (
highWaterMark=1) wurde auf Byte-Streams (highWaterMark=4096 usw.) umgestellt, um die Verarbeitung großer Datenmengen zu optimieren
- Künftige Patches zur Verbesserung der Stream-Verarbeitung in Next.js und React sollen ebenfalls Upstream in übergeordnete Plattformen einfließen
Leistungsproblem bei JSON.parse() und V8-Patch
- In Next.js und React insgesamt traten übermäßig viele Aufrufe bei der Verwendung von
JSON.parse() mit reviver-Option auf (mehr als 100.000-mal)
- Im aktuellen ECMAScript-Standard kann der reviver einen dritten Parameter (Source Context) erhalten, was die Performance zusätzlich verschlechterte (gemeinsam in Firefox, Chrome usw.)
- Das Team von Cloudflare Workers lieferte einen Patch für die V8-Engine (33 % Leistungsverbesserung), von dem das gesamte Ökosystem einschließlich Node.js, Chrome-Browser und Deno profitieren soll
Leistungsproblem trigonometrischer Funktionen in Node.js
- Unabhängig von Theos Benchmark wurde berichtet, dass Cloudflare Workers in einem Benchmark mit wiederholten Aufrufen mathematischer trigonometrischer Funktionen (
sin, cos usw.) dreimal schneller war
- Die Ursache war, dass Node.js den von V8 bereitgestellten aktuellen/schnellen Pfad für trigonometrische Funktionen (Compile-Time-Flag) noch nicht übernommen hatte
- Cloudflare Workers hatte dieses Flag zufällig standardmäßig aktiviert; für Node.js wurde ein Patch per Pull Request eingereicht
- Da auch dieses Problem das Open-Source-Ökosystem insgesamt betrifft, wird bei Übernahme in AWS Lambda und Vercel eine allgemeine Stabilisierung der Geschwindigkeit erwartet
Grenzen und Erkenntnisse bei Benchmark-Design und Messung
- Die Benchmarks maßen größtenteils die Request-Zeit (Latenz) vom Client aus und nicht direkt die tatsächliche serverseitige CPU-Nutzungszeit
- Verschiedene nicht direkt vergleichbare Variablen wie Netzwerkpfad, Standort des Rechenzentrums, Hardware-Generation und Multi-Tenancy können die Ergebnisse beeinflussen
- Wenn nur die Time to First Byte (TTFB) gemessen wird, lässt sich die vollständige Render-/Übertragungszeit nur schwer abbilden. Ein Wechsel zu TTFL könnte noch empfindlicher auf Unterschiede in der Netzwerkgeschwindigkeit reagieren
- Je nach Vielfalt von Server-Hardware/-Software und Zufall bei der Instanzzuweisung gibt es auch temporäres oder korreliertes Rauschen
- Die präzisere Definition von Benchmark-Umgebung und Workflows sowie das Angleichen von Variablen führten zu praxisnahen Verbesserungen, von denen sowohl eigene als auch fremde Plattformen profitieren
Während der Experimente entdeckte Probleme bei Benchmark und Umgebungskonfiguration
- Unterschiede bei nicht angewendeter force-dynamic-Konfiguration in Next.js, Caching-Logik und Response-Streaming bargen das Risiko von Fehlinterpretationen der Ergebnisse
- Im React-SSR-Benchmark lief wegen einer nicht gesetzten Umgebungsvariable
NODE_ENV der Dev-Modus, was langsamere Ergebnisse als realistisch lieferte
- Diese Fehler wurden durch explizites Setzen der Umgebungsvariablen behoben
Ausblick und Fazit
- Verschiedene Leistungsverbesserungen in der Cloudflare Workers Runtime sind bereits vollständig ausgerollt, Nutzer profitieren ohne eigenes Zutun davon
- Theo erhielt Pull Requests mit Testcode und OpenNext-Optimierungen
- Weitere Verbesserungen sind geplant, um die Lücke zwischen OpenNext und dem auf Vercel basierenden Next.js zu schließen
- Der Scheduling-Algorithmus sowie Open-Source-Engines wie V8 und Node.js sollen kontinuierlich weiterentwickelt werden; außerdem will man weiter zur Community beitragen
- Durch bessere Benchmarks und Profiling sollen potenzielle Probleme früh entdeckt sowie Optimierungen und eine Kultur des Teilens fortgeführt werden
Referenzen und zusätzliche Links
1 Kommentare
Hacker-News-Kommentare
Es ist gut, dass CF tatsächlich versucht, das Produkt zu verbessern. Allerdings ändern sich die Dinge so schnell, dass man kaum hinterherkommt, und oft kommt der Release vor der Ausgereiftheit. Zum Beispiel fehlt dem R2 Data Catalog immer noch die Unterstützung für Iceberg v3, Wrangler hat sich schon innerhalb weniger Monate stark verändert, und es wirkt, als würde Pages bald verschwinden, sodass die Migration zu Workers Assets ziemlich mühsam ist. Konfigurationen, die in Wrangler 3 gut funktioniert haben, wurden in Wrangler 4 nicht korrekt übernommen, und bei Wrangler 5 scheint schon wieder ein neues Interaktionsmodell zu kommen
Zu der Aussage, dass „Pages wohl verschwinden wird“: In einem Community-Post hat CF tatsächlich erwähnt, dass Pages nicht abgeschafft wird, bevor Workers auf demselben Stand wie Pages ist Zugehöriger Post Offiziell ist schwer etwas dazu zu finden, dass Pages eingestellt würde, und sowohl pages.cloudflare.com als auch developer.cloudflare.com/pages werden aktiv betrieben. Ein Reddit-Post deutet zwar eine Migration von Pages an, aber auch dort gibt es keinen offiziellen Hinweis auf eine Einstellung Den übrigen Punkten stimme ich zu, und genau dieser Teil hat mich besonders überrascht Reddit-Link als Referenz
Der Aussage, dass Konfigurationen aus Wrangler 3 in Wrangler 4 nicht unverändert funktionieren, kann ich nicht zustimmen. Am Konfigurationsformat hat sich in Wrangler 4 überhaupt nichts geändert, und der Grund für den Major-Version-Sprung betraf 99,99 % der Nutzer überhaupt nicht. Die entsprechenden Änderungen sind hier dokumentiert. Schon allein ein Major-Version-Upgrade ist lästig genug, deshalb habe ich intern auch Einwände geäußert, aber wegen extrem seltener Ausnahmefälle war das Team vorsichtig. Künftig wollen wir Wege entwickeln, solche Themen ohne Major-Version-Sprünge zu handhaben, etwa durch parallele Unterstützung von esbuild-Versionen. Auf Runtime-Seite achten wir besonders stark auf Abwärtskompatibilität Blog zur Abwärtskompatibilität Pages verschwindet nicht, und Workers Assets ist eine flexiblere Implementierungsvariante von Pages. Wenn man die zusätzlichen Funktionen nicht braucht, muss man nicht migrieren, und später ist auch eine automatische Migration geplant
Das erinnert noch einmal daran, dass man für wichtige Projekte oder Systeme, die über Jahre gepflegt werden sollen, besser auf „boring tech“ setzt
Mich würde interessieren, worauf sich die Aussage „Pages wird wohl verschwinden“ stützt. Ich nutze Pages in mehreren Projekten problemlos
Interessant ist, dass diese Debatte mit der Behauptung begann, Cloudflare sei schneller als Vercel. Danach hat jemand mit echtem Fachwissen einen Benchmark durchgeführt, und in Wirklichkeit kam das Gegenteil heraus. Das führte letztlich dazu, dass Cloudflare tatsächlich Verbesserungen an der Performance umgesetzt hat
Mir gefällt sehr, dass der Artikel nicht die Konkurrenz angreift, sondern Verbesserungsmöglichkeiten herausarbeitet und hervorhebt. Beeindruckend ist auch, dass es Fortschritte bei der OpenNext-Implementierung gibt, die sich bei anderen Anbietern wiederverwenden lassen
Ich hoste NextJS derzeit noch bei Vercel und migriere gerade zu Astro/React auf Cloudflare. Das Erstaunliche ist, dass selbst dann, wenn die Web-App bei jeder Anfrage am „Edge“ gerendert wird, die Antwortzeiten bei etwa 100–200 ms liegen und damit fast an statische Seiten heranreichen. In den letzten Wochen habe ich die Verbesserungen bei Cloudflare Workers auch deutlich gespürt: Cold Starts sind fast verschwunden, und die Antwortzeiten sind viel stabiler geworden Link zur Web-App in Migration
Spannend, dass sich ein Video eines nicht besonders großen YouTubers auf diese Weise so effektiv verbreitet hat und am Ende bei Cloudflare zu tatsächlich sinnvollen Verbesserungen und zur Behebung von Plattformproblemen geführt hat
Das ist extrem gut gemachte PR. Lob an alle, die diesen Post vorbereitet haben
Als langjähriger cf-Kunde kann ich sagen: cf schreibt nicht nur gute Blogposts und Open-Source-Texte, sondern bietet unter den Infrastrukturunternehmen auch den besten Support. Teammitglieder, darunter auch Kenton, helfen Nutzern direkt auf Discord oder greifen Feedback auf, und bei Bugs oder Problemen kann man oft direkt mit den verantwortlichen Engineers sprechen. PRs oder Feature-Requests, die ich selbst vorgeschlagen habe, wurden tatsächlich ohne große Prozesse schnell umgesetzt. Im Vergleich zu anderen großen Unternehmen bekomme ich zu deutlich niedrigeren Preisen viel besseren Support
Danke! Diese PR und der Post wurden vollständig von Engineers des Workers-Teams initiiert und umgesetzt (ich war auch beteiligt)
Mir gefällt sehr, wie dieser Post geschrieben ist, wie die Informationen aufgeschlüsselt werden und wie offen die Diskussion geführt wird. Das stärkt mein Vertrauen in das Cloudflare-Workers-Team
Meiner Meinung nach ist SvelteKit extrem schnell, während Next.js im Vergleich sehr langsam ist
Klingt nach einer plausiblen Schlussfolgerung
Ich hoffe, dass pragmatische Frameworks wie SvelteKit, Astro und TanStack die Komplexität von NextJS bald ablösen
Genau solche Fälle zeigen, warum Wettbewerb und unabhängige Benchmarks nötig sind. Sie bringen auch leistungsschwächere Dienste dazu, an Verbesserungen zu arbeiten
Solche Bemühungen wirken aber nur, wenn einem das Produkt wirklich wichtig ist
Unabhängige Benchmarks gibt es bereits
Beeindruckend, wie Cloudflare das Ergebnis demütig aufgenommen und konstruktiv Verbesserungen vorgenommen hat
Ein guter Text, der sich auf den Inhalt konzentriert und niemanden angreift. Allerdings überrascht es mich, dass Cloudflare Dinge wie die Größe der Generationen nicht schon früher besser überwacht und angepasst hat. Aus meiner Erfahrung mit JVM-Performance-Tuning gehören Einstellungen der Generation Size zu den Grundlagen