WebAssembly-Kaltstart: Was Benchmarks zeigen

Der Kaltstart ist wieder einmal zu einer Achse der kommerziellen Differenzierung zwischen WebAssembly-Laufzeiten geworden und nicht nur Gegenstand akademischer Forschung. Wasmer macht dies zu einem expliziten Verkaufsargument mit einer Funktion namens Instaboot, die als direkte Antwort auf das Kaltstartproblem präsentiert wird.

Dieser Reflex erinnert genau an die Dynamik, die bereits in unserem Artikel über die Backend-Benchmark-Methodik dokumentiert wurde: Mehrere konkurrierende Anbieter zeigen Leistungsdaten auf ihrer eigenen Produktseite an, ohne immer das Protokoll anzugeben, das sie erstellt hat. Eine Kaltstartzahl ohne Methode beweist nichts anderes als eine Latenzzahl ohne Methode.

Ein Kaltstart ist kein einzelner Vorgang, sondern eine Summe unterschiedlicher Phasen, und zwei Lieferanten messen nicht unbedingt dieselben Phasen unter demselben Namen.

Eine Zahl, die nur die Instanziierung eines bereits geladenen und bereits in den Speicher kompilierten Moduls zählt, sieht mechanisch besser aus als eine Zahl, die das Laden und Kompilieren über das Netzwerk umfasst. Beides ist an sich nicht falsch: Das Problem tritt auf, wenn wir sie vergleichen, ohne anzugeben, welches der beiden gemessen wurde.

In den letzten Jahren wurde in wissenschaftlichen Arbeiten, die als Preprint auf arXiv veröffentlicht wurden, die Instanziierungszeit von WebAssembly-Modulen auf verschiedenen Laufzeiten gemessen. Der gemeinsame Punkt zwischen diesen Arbeiten ist kein konvergenter Wert: Es handelt sich um einen signifikanten Unterschied, der von der getesteten Laufzeit, der Größe des Moduls und der verwendeten Hardware abhängt.

Auf die Angabe konkreter Zahlen aus diesen Veröffentlichungen verzichten wir in diesem Artikel freiwillig. Ohne die Methodik jedes Artikels zum Zeitpunkt des Schreibens gründlich überprüft zu haben, würde die erneute Veröffentlichung einer isolierten Zahl genau das Problem reproduzieren, das dieser Artikel dokumentiert: eine Zahl ohne den Kontext, der es uns ermöglichen würde, zu wissen, was sie wirklich misst.

Was diese Varianz hingegen lernt, ist direkt nützlich: Ein Kaltstart hängt stark vom Messkontext ab, genau wie es die Disziplin der Umgebungsparität in unserem Artikel zur allgemeinen Methodik beschreibt (identische Hardware, gleiche Region, gleicher Cache-Status für alle verglichenen Systeme).

Die drei in dieser Debatte am häufigsten genannten eigenständigen WebAssembly-Laufzeiten bringen Kompilierungsgeschwindigkeit und Ausführungsleistung nicht auf die gleiche Weise in Einklang, was teilweise erklärt, warum ihre Kaltstartzahlen nicht von Begriff zu Begriff vergleichbar sind.

Die vollständigen Architekturdetails zwischen den beiden Laufzeiten, die in serverlosen Diskussionen am häufigsten kontrovers diskutiert werden, finden Sie in unserem speziellen Vergleich Wasmtime vs. Wasmer.

Gemäß der Produktpositionierung, die Wasmer öffentlich kommuniziert, stellt Instaboot eine bereits initialisierte Instanz durch einen Snapshot-Mechanismus wieder her, anstatt bei jeder Anfrage einen kompletten Startvorgang neu zu starten. Es handelt sich um eine echte architektonische Entscheidung, die im Einklang mit dem Problem steht, auf das sie abzielt.

Was dieser Artikel jedoch nicht tut, ist die Wiederholung einer auf der Wasmer-Produktseite angezeigten Leistungszahl. Ohne zu wissen, welche Hardware, welche Arbeitslast und welches Messprotokoll diese Zahl erzeugt hat, würde eine erneute Veröffentlichung genau den oben dokumentierten Fehler begehen: eine Marketingzahl als unabhängiges Benchmark-Ergebnis zu behandeln.

Aurabase führt seine Edge-Funktionen auf Wasmtime in der Produktion aus, nicht in einem Pilotprojekt. Hier erfahren Sie genau, was die Einreichung zulässt und wo dieser Anspruch endet.

Die Abhängigkeit wird als hart deklariert, wobei die Funktionen async und cranelift aktiviert sind, in den Produktionsabhängigkeiten des Dienstes, nicht in einem dev-dependency oder einem Kommentar:

# Tatsächlicher Auszug aus dem Repository
[dependencies]

# WASM-Laufzeit
wasmtime = { version = "43", features = ["async", "cranelift"] }

What this file does not say: no cold start figures measured according to the protocol described in our benchmark methodology exist today in the repository for this runtime. Until a dated measurement, with disaggregated percentiles, hardware and workload, has been published, no Aurabase figure should be cited as a measured characteristic of the product. For the general architecture of the platform, see our pillar article Aurabase Rust architecture. For a concrete comparison between cold start WASM and cold start container, independent of the methodological question addressed here, see our dedicated article WASM vscontainers.

Sieben Fragen, die man jeder Kaltstartfigur stellen sollte, auch unserer am Tag der Veröffentlichung.

1. Welche Phasen sind enthalten? Netzwerkladen, Validierung, Kompilierung, Instanziierung, erster Aufruf: Eine Zahl, die nur einen Teil davon zählt, ist nicht mit einer Zahl vergleichbar, die sie alle zählt.
2. War das Modul wirklich „kalt“? Ein Modul, das sich bereits im Speicher oder im Festplatten-Cache befindet, testet nicht dasselbe wie ein Modul, das zum ersten Mal geladen wird.
3. JIT-Kompilierung oder vorkompiliertes Artefakt (AOT)? Die beiden Strategien haben strukturell unterschiedliche Startkosten.
4. Einzahlig oder Verteilung? Ein bester Lauf in zehn Läufen hat nicht den gleichen Wert wie ein p95 in tausend Läufen.
5. Gerät und Region angegeben? Eine Figur ohne Hardwarespezifikation kann nicht von Dritten reproduziert werden.
6. Vergleich bei gleicher Last und Topologie? Der Vergleich einer selbstgehosteten Laufzeit mit einem verwalteten Dienst, ohne dies zu melden, verzerrt die Lesart.
7. Datum und Version der getesteten Laufzeit? Eine undatierte Zahl zu einem Projekt, das sich schnell weiterentwickelt, bedeutet nach ein paar Monaten nichts mehr.