Serverless Everywhere: A Comparative Analysis of WebAssembly Workflows Across Browser, Edge, and Cloud
Metadane
- Autorzy: Mario Colosi, Reza Farahani, Lauri Lovén, Radu Prodan, Massimo Villari
- Rok: 2025
- Źródło: arXiv preprint (University of Messina, University of Klagenfurt, University of Oulu, University of Innsbruck)
- arXiv: 2512.04089
- PDF: https://arxiv.org/pdf/2512.04089v1
- Status: to-read
- Kategoria główna: Systems
- Podkategorie: WebAssembly, Serverless, Edge Computing, Cloud, Browser
- Tagi:
#webassembly#wasm#serverless#edge-computing#cloud#browser#aot#jit#performance#project:js-runtime-energy
Streszczenie
Praca bada workflow WebAssembly wykonywalny spójnie w przeglądarce, na edge i w chmurze — “serverless everywhere”. Używa modułów wasm32-wasi, w przeglądarce wykonywanych w web worker, a na edge/cloud przez HTTP shim. Mierzy cold/warm start latency, throughput i CPU/memory dla wszystkich trzech środowisk.
Wyniki: AOT kompilacja i instance warming znacząco redukują latencję startu. Dla małych payloadów przeglądarka jest konkurencyjna (dane in-memory). Dla dużych payloadów edge/cloud z AOT wyraźnie przewyższa przeglądarkę.
Kluczowe Wnioski
- AOT compilation: kluczowy czynnik wydajności — radykalnie redukuje overhead inicjalizacji Wasm
- Instance warming: podgrzewanie instancji istotnie poprawia latencję (analogia do keep-warm w FaaS)
- Przeglądarka: kompetytywna dla małych payloadów (brak network overhead, dane in-memory)
- Edge/Cloud z AOT: wyraźnie lepsza dla dużych, compute-intensive zadań
- Spójność wykonania Wasm przez wasm32-wasi na wszystkich platformach umożliwia “write once, run everywhere”
- CPU/memory utilization różni się istotnie między środowiskami
Metodologia
- Workflow: wasm32-wasi modules (video processing workflow)
- Przeglądarka: Web Worker + JavaScript interop
- Edge/Cloud: HTTP shim streaming frames do Wasm runtime
- Mierzone metryki: cold/warm start latency, per-step delays, makespan, throughput, CPU/memory
- Środowiska: browser (Chrome/Firefox) + edge nodes + cloud VMs
- Tryby kompilacji: AOT vs JIT (porównanie)
Główne Koncepcje
- wasm32-wasi: standard Wasm dla systemowego interfejsu — uruchamialny poza przeglądarką
- Web Worker: mechanizm przeglądarki dla background threads — umożliwia Wasm bez blokowania UI
- HTTP Shim: warstwa tłumacząca HTTP requests na Wasm execution poza przeglądarką
- Workflow makespan: całkowity czas od startu do zakończenia pipeliny (end-to-end)
- Payload size transition: punkt przejścia gdy edge/cloud staje się lepszy niż przeglądarka
Wyniki
| Środowisko | Cold start | Warm performance | Najlepsze dla |
|---|---|---|---|
| Browser | Medium | Dobre (małe payloady) | Małe payloady, brak network |
| Edge (AOT) | Małe | Bardzo dobre | Medium-large payloady |
| Cloud (AOT) | Małe | Najlepsze (large) | Duże compute-intensive |
Przydatne Cytaty
“AOT compilation and instance warming substantially reduce startup latency.” (Abstract)
“For workflows with small payloads, the browser achieves competitive performance owing to fully in-memory data exchanges.” (Abstract)
Datasety
- Własne pomiary (video processing workflow)
Powiązane Tematy
- Lumos 2025 (performance model Wasm w edge-cloud)
- Besozzi 2025 (Wasm vs unikernels)
- CWASI 2025 (inter-function communication Wasm)
- Gap: brak pomiaru energii dla browser/edge/cloud Wasm