Cloudflare Workers lassen sich jetzt in Produktion profilen, CPU und Speicher auf Abruf
Serguey Asael Shinder2 Min. LesezeitCloudflare hat am 9. Oktober angekündigt, dass sich Workers und Durable Objects auf Abruf in Produktion profilen lassen. Im Observability-Tab eines Workers, per API oder mit der cf-CLI fordert man ein CPU- oder Speicherprofil einer laufenden Version an, sieht es als interaktiven Flamegraph oder als sortierbare Tabelle und kann die Profildatei für andere Werkzeuge herunterladen. Bisher ging Profiling nur lokal über die Chrome DevTools — ohne echten Produktionsverkehr.
Wie gemessen wird, ohne den Code anzuhalten. Die Laufzeit hält die Isolate-Sperre nur zum Starten und Stoppen. Für ein CPU-Profil legt sie einen V8-CPU-Profiler mit Abtastung im Millisekundentakt an, gibt die Sperre frei, damit Anfragen weiterlaufen, wartet die gewünschte Dauer ab, holt die Sperre zum Stoppen zurück und serialisiert das Ergebnis außerhalb des kritischen Abschnitts. Würde sie die Sperre die ganze Zeit halten, stünde genau der Code still, der gemessen werden soll.
Die Einschränkung, mit der man planen muss: Es wird beobachtet, nicht gestartet. Für ein Profil wird kein neues Isolate hochgefahren, weil echte Produktionsausführung erfasst werden soll. Eine Version mit wenig Traffic lässt sich daher kaum oder gar nicht profilen; Cloudflare rät, eine ausgerollte Version mit ausreichend Anfragen zu wählen. Gewöhnliche Workers sind zustandslos, also wird zufällig eines der laufenden Isolates gewählt. Bei Durable Objects gibt man dagegen den Namen des Objekts an, und die Anfrage landet auf dem Rechner, der genau diesen Akteur hält — für die Fehlersuche an Zustand ist das der eigentliche Gewinn.
Zwei Beispiele aus Cloudflares eigenen Diensten. Im Worker hinter dem R2-Binding lief ein von JSON.stringify aufgerufener Replacer zusätzlich selbst durch den Baum, tief verschachtelte Werte wurden mehrfach verarbeitet. Er kostete über 5 % der CPU-Zeit; nach dem Fix war die Funktion 2,7-mal schneller. Ein doppelter Metrik-Aufruf kostete allein etwa 1 %. In einem anderen Worker lag der P999-Speicher bei rund 133 MB bei einem Limit von 128 MB, mit Verdrängungen wegen Exceeded Memory. Ein Heap-Profil zeigte, dass für abgeschaltet gehaltener Instrumentierungscode etwa zwei Drittel der Allokationen verursachte; nach dem Entfernen blieben rund 10 MB Luft.
Grenzen, die Cloudflare selbst nennt: Eine Sitzung muss man von Hand starten und verpasst dabei womöglich genau den Moment, in dem etwas schiefgeht; der Speicherprofiler zeigt nur Allokationen innerhalb des Zeitfensters, Allokationen beim Start bleiben unsichtbar. Als Nächstes ist kontinuierliches Profiling geplant, das seltene Ereignisse erfassen soll. In TypeScript-Projekten müssen Source Maps aktiv sein, sonst zeigt der Flamegraph unlesbare Funktionsnamen.
Quelle: Cloudflare Blog, On-demand CPU and memory profiling for Workers and Durable Objects, 9. Oktober 2026 — https://blog.cloudflare.com/workers-on-demand-profiling/