WebAssembly koude start: wat benchmarks laten zien

De koude start is opnieuw een as van commerciële differentiatie tussen WebAssembly-runtimes geworden, en niet alleen een onderwerp van academisch onderzoek. Wasmer maakt hier een expliciet verkoopargument van met een functie genaamd Instaboot, gepresenteerd als een direct antwoord op het koude startprobleem.

Deze reflex doet precies denken aan de dynamiek die al is gedocumenteerd in ons artikel over de backend benchmark-methodologie: verschillende concurrerende leveranciers geven prestatiecijfers weer op hun eigen productpagina, zonder altijd het protocol te specificeren dat deze heeft geproduceerd. Een koudestartcijfer zonder methode bewijst niets meer dan een latentiecijfer zonder methode.

Een koude start is geen enkele handeling: het is een optelsom van verschillende fasen, en niet noodzakelijkerwijs meten twee leveranciers dezelfde fasen onder dezelfde naam.

Een cijfer dat alleen de instantiatie meet van een module die al is geladen en al in het geheugen is gecompileerd, zal er mechanisch beter uitzien dan een cijfer dat het laden en compileren van het netwerk omvat. Geen van beide is op zichzelf onwaar: het probleem doet zich voor als we ze vergelijken zonder te specificeren welke van de twee is gemeten.

Academisch werk dat de afgelopen jaren als preprint op arXiv is gepubliceerd, heeft de instantiatietijd van WebAssembly-modules op verschillende runtimes gemeten. Het gemeenschappelijke punt tussen deze werken is geen convergent cijfer: het is een significant verschil, afhankelijk van de geteste runtime, de grootte van de module en de gebruikte hardware.

In dit artikel nemen wij vrijwillig geen exacte cijfers uit deze publicaties op. Zonder de methodologie van elk artikel op het moment van schrijven grondig te hebben gecontroleerd, zou het opnieuw publiceren van een geïsoleerd getal precies het probleem reproduceren dat dit artikel beschrijft: een getal zonder de context die ons in staat zou stellen te weten wat het werkelijk meet.

Wat deze variantie aan de andere kant leert, is direct nuttig: een koude start hangt sterk af van de meetcontext, precies zoals herinnerd door de discipline van omgevingspariteit, beschreven in ons artikel over algemene methodologie (identieke hardware, dezelfde regio, dezelfde cachestatus voor alle vergeleken systemen).

De drie op zichzelf staande WebAssembly-runtimes die het meest in dit debat worden genoemd, houden de compilatiesnelheid en uitvoeringsprestaties niet op dezelfde manier in evenwicht, wat gedeeltelijk verklaart waarom hun koudestartcijfers niet van term tot term vergelijkbaar zijn.

Voor de volledige architectonische details tussen de twee runtimes die het vaakst tegengesteld zijn in serverloze discussies, zie onze speciale vergelijking Wasmtime vs Wasmer.

Volgens de productpositionering die Wasmer publiekelijk communiceert, herstelt Instaboot een exemplaar dat al is geïnitialiseerd door een snapshot-mechanisme, in plaats van bij elk verzoek een volledig opstarten opnieuw te starten. Het is een echte architecturale keuze die consistent is met het probleem dat ermee wordt beoogd.

Wat dit artikel echter niet doet, is een prestatiecijfer herhalen dat op de Wasmer-productpagina wordt weergegeven. Zonder te weten welke hardware, welke werklast en welk meetprotocol dit cijfer hebben opgeleverd, zou het opnieuw publiceren ervan precies de hierboven gedocumenteerde fout maken: een marketingnummer behandelen als een onafhankelijk benchmarkresultaat.

Aurabase voert zijn Edge-functies uit op Wasmtime in productie, niet in een pilotproject. Dit is precies wat de indiening mogelijk maakt en waar die claim eindigt.

De afhankelijkheid wordt hard verklaard, met de functies async en cranelift geactiveerd, in de productieafhankelijkheden van de service, niet in een dev-dependency, noch een commentaar:

# Werkelijk uittreksel uit de repository
[dependencies]

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

Wat dit bestand niet zegt: er bestaan ​​momenteel geen koudestartcijfers gemeten volgens het protocol beschreven in onze benchmarkmethodologie in de repository voor deze runtime. Totdat een gedateerde meting, met uitgesplitste percentielen, hardware en werklast, is gepubliceerd, mag geen Aurabase-cijfer worden aangehaald als gemeten kenmerk van het product. Voor de algemene architectuur van het platform, zie ons pijlerartikel Aurabase Rust-architectuur. Voor een concrete vergelijking tussen koude start WASM en koude start container, onafhankelijk van de methodologische vraag die hier wordt behandeld, zie ons speciale artikel WASM versuscontainers.

Zeven vragen die je aan elk koudstartfiguur kunt stellen, inclusief de onze op de dag dat we er een uitbrengen.

1. Welke fasen zijn inbegrepen? Netwerkbelasting, validatie, compilatie, instantiatie, eerste oproep: een cijfer dat slechts een deel ervan telt, is niet vergelijkbaar met een cijfer dat ze allemaal telt.
2. Was de module echt “koud”? Een module die zich al in het geheugen of de schijfcache bevindt, test niet hetzelfde als een module die voor de eerste keer wordt geladen.
3. JIT-compilatie of voorgecompileerd artefact (AOT)? De twee strategieën hebben structureel verschillende opstartkosten.
4. Eén cijfer of verdeling? Een beste serie op tien heeft niet dezelfde waarde als een p95 op duizend runs.
5. Uitrusting en regio gespecificeerd? Een figuur zonder hardwarespecificatie kan niet door derden worden gereproduceerd.
6. Vergelijking bij gelijke belasting en topologie? Het vergelijken van een zelf-hostende runtime met een beheerde service zonder dit te melden, vertekent de lezing.
7. Datum en versie van de geteste runtime? Een ongedateerd cijfer over een project dat snel evolueert, betekent na een paar maanden niets meer.