Avvio a freddo di WebAssembly: cosa mostrano i benchmark

L'avvio a freddo è diventato ancora una volta un asse di differenziazione commerciale tra i runtime WebAssembly, non solo un argomento di ricerca accademica. Wasmer rende questo un punto di forza esplicito con una funzionalità chiamata Instaboot, presentata come una risposta diretta al problema dell'avvio a freddo.

Questo riflesso ricorda esattamente la dinamica già documentata nel nostro articolo sulla metodologia di benchmark del backend : diversi fornitori concorrenti mostrano i dati sulle prestazioni sulla propria pagina di prodotto, senza sempre specificare il protocollo che li ha prodotti. Un valore di avvio a freddo senza metodo non dimostra altro che un valore di latenza senza metodo.

Una partenza a freddo non è una singola operazione: è una somma di fasi distinte, e non è detto che due fornitori misurino le stesse fasi con lo stesso nome.

Una figura che conta solo l'istanziazione di un modulo già caricato e già compilato in memoria avrà un aspetto meccanicamente migliore di una figura che include il caricamento e la compilazione della rete. Nessuno dei due è falso di per sé: il problema si presenta quando li confrontiamo senza specificare quale dei due è stato misurato.

Il lavoro accademico pubblicato come preprint su arXiv negli ultimi anni ha misurato il tempo di istanziazione dei moduli WebAssembly su diversi runtime. Il punto in comune tra questi lavori non è una cifra convergente: si tratta di una differenza significativa a seconda del runtime testato, della dimensione del modulo e dell'hardware utilizzato.

Non includiamo volontariamente in questo articolo cifre precise tratte da queste pubblicazioni. Senza aver ricontrollato accuratamente la metodologia di ciascun articolo al momento della stesura, ripubblicare un numero isolato riprodurrebbe esattamente il problema documentato in questo articolo: un numero senza contesto che ci permetterebbe di sapere cosa misura realmente.

Ciò che questa varianza apprende, invece, è direttamente utile: un avvio a freddo dipende fortemente dal contesto di misurazione, esattamente come richiamato dalla disciplina della parità ambientale descritta nel nostro articolo sulla metodologia generale (hardware identico, stessa regione, stesso stato della cache per tutti i sistemi confrontati).

I tre runtime WebAssembly autonomi più citati in questo dibattito non bilanciano la velocità di compilazione e le prestazioni di esecuzione nello stesso modo, il che spiega in parte perché i dati relativi all'avvio a freddo non si confrontano da termine a termine.

Per i dettagli architettonici completi tra i due runtime più spesso opposti nelle discussioni serverless, vedere il nostro confronto dedicato Wasmtime vs Wasmer.

Secondo il posizionamento del prodotto che Wasmer comunica pubblicamente, Instaboot ripristina un'istanza già inizializzata tramite un meccanismo di snapshot, anziché riavviare un avvio completo ad ogni richiesta. Si tratta di una vera e propria scelta architetturale coerente con il problema che si pone.

Ciò che questo articolo non fa, tuttavia, è ripetere un dato relativo alle prestazioni visualizzato nella pagina del prodotto Wasmer. Senza sapere quale hardware, quale carico di lavoro e quale protocollo di misurazione ha prodotto questa cifra, ripubblicarla commetterebbe esattamente l’errore documentato sopra: trattare un numero di marketing come un risultato di benchmark indipendente.

Aurabase esegue le sue funzioni Edge su Wasmtime in produzione, non in un progetto pilota. Ecco esattamente cosa consente il deposito e dove finisce tale affermazione.

La dipendenza è dichiarata hard, con le funzionalità async e cranelift attivate, nelle dipendenze di produzione del servizio, non in un dev-dependency né in un commento:

# Estratto effettivo dal repository
[dependencies]

# Tempo di esecuzione WASM
wasmtime = { version = "43", features = ["async", "cranelift"] }

Cosa non dice questo file: non esistono dati di avvio a freddo misurati secondo il protocollo descritto nella nostra metodologia di benchmark oggi nel repository per questo runtime. Fino alla pubblicazione di una misurazione datata, con percentili disaggregati, hardware e carico di lavoro, nessuna cifra Aurabase dovrebbe essere citata come caratteristica misurata del prodotto. Per l'architettura generale della piattaforma, consultare il nostro articolo pilastro Architettura Aurabase Rust. Per un confronto concreto tra WASM con avvio a freddo e contenitore con avvio a freddo, indipendentemente dalla questione metodologica qui affrontata, vedere il nostro articolo dedicato WASM vscontenitori.

Sette domande da porre a qualsiasi figura di partenza a freddo, inclusa la nostra il giorno in cui ne pubblicheremo una.

1. Quali fasi sono incluse? Caricamento della rete, validazione, compilazione, istanziazione, prima chiamata: una figura che ne conta solo una parte non è paragonabile a una figura che le conta tutte.
2. Il modulo era davvero “freddo”? Un modulo già in memoria o nella cache del disco non verifica la stessa cosa di un modulo caricato per la prima volta.
3. Compilazione JIT o artefatto precompilato (AOT)? Le due strategie hanno costi di avvio strutturalmente diversi.
4. Cifra singola o distribuzione? Un miglior giro su dieci non ha lo stesso valore di un p95 su mille giri.
5. Attrezzatura e regione specificate? Una figura senza specifiche hardware non può essere riprodotta da terzi.
6. Confronto a parità di carico e topologia? Il confronto tra un runtime self-hosted e un servizio gestito senza segnalare distorce la lettura.
7. Data e versione del runtime testato? Un dato senza data su un progetto che si evolve velocemente non significa più nulla dopo pochi mesi.