Lumos: Performance Characterization of WebAssembly as a Serverless Runtime in the Edge-Cloud Continuum

Metadane

• Autorzy: Cynthia Marcelino, Noah Krennmair, Thomas Pusztai, Stefan Nastic
• Rok: 2025
• Źródło: 15th International Conference on the Internet of Things (IOT 2025), Vienna, Austria. ACM.
• DOI: 10.1145/3770501.3770515
• arXiv: 2510.05118
• PDF: https://arxiv.org/pdf/2510.05118v1
• Status: to-read
• Kategoria główna: Systems
• Podkategorie: Serverless Computing, WebAssembly, Edge Computing, Benchmarking
• Tagi: #webassembly #wasm #serverless #edge-computing #performance #benchmark #cloud #cold-start #project:js-runtime-energy

Streszczenie

Lumos to model wydajnościowy i narzędzie benchmarkowe do charakteryzowania środowisk uruchomieniowych serverless w Edge-Cloud Continuum. Praca identyfikuje czynniki wpływające na wydajność na trzech poziomach: workload, system i środowisko. Benchmarkuje kontenery i runtime Wasm (interpretowany + AoT-kompilowany).

Kluczowe wyniki: AoT-kompilowane obrazy Wasm są do 30× mniejsze i zmniejszają latencję cold start o do 16% w porównaniu z kontenerami, natomiast interpretowany Wasm cierpi na 30–55× wyższą latencję warm i 7–10× narzut I/O-serializacji.

Kluczowe Wnioski

• AoT Wasm > kontenery w cold start latency (do 16% lepsza) i rozmiarze obrazu (30× mniejszy)
• Interpretowany Wasm << kontenery w warm latency (30–55× gorszy) — nienadający się do produkcji
• I/O-serializacja przez WASI jest głównym bottleneckiem dla data-intensive workloadów (7–10× overhead)
• Performance zależy silnie od charakteru workloadu: compute-intensive vs data-intensive
• Model wydajnościowy Lumos: 3 wymiary — workload (CPU/IO), system (runtime/compilacja), environment (edge/cloud)
• Framework benchmarkowy jest open-source i reprodukowalny

Metodologia

• Runtimes porównywane: Docker containers + Wasm (interpretowany) + Wasm AoT (ahead-of-time compilation)
• Platforma benchmarkowa: Lumos — automatyczne uruchamianie, zbieranie metryk, różne poziomy concurrency
• Mierzone metryki: cold/warm start latency, throughput, CPU/memory usage, I/O-serializacja
• Workloady: compute-intensive (matrix multiply, hashing) + data-intensive (JSON serialize/deserialize + BaaS access)
• Środowiska: edge nodes (RPi, Jetson) + cloud (GKE)
• NIE mierzy energii — tylko wydajność/latencję

Główne Koncepcje

• Edge-Cloud Continuum: heterogeniczne środowisko od urządzeń edge (resource-constrained) do chmury
• AoT (Ahead-of-Time) compilation: kompilacja Wasm do kodu natywnego przed uruchomieniem — brak JIT overhead
• WASI (WebAssembly System Interface): standardowy interfejs Wasm do systemu operacyjnego — filesystem, network
• Cold start vs warm start: cold = od zera (inicjalizacja runtime), warm = funkcja już w pamięci
• BaaS (Backend-as-a-Service): zewnętrzne usługi (storage, DB) używane przez serverless functions

Wyniki

Dla data-intensive: I/O overhead WASI dominuje — Wasm gorszy od kontenerów niezależnie od trybu kompilacji.

Przydatne Cytaty

“AoT-compiled Wasm images are up to 30x smaller and decrease cold-start latency by up to 16% compared to containers, while interpreted Wasm suffers 30–55x higher warm latency and 7–10x I/O-serialization overhead.” (Abstract)

“Wasm enables next-generation serverless computing by offering a portable, secure, and lightweight execution model.” (Section 1)

“data IO can impact function execution time by up to 95%.” (Section 2, citing other work)

Datasety

• Własne pomiary benchmarkowe (Lumos tool — open-source)
• Workload traces: compute-intensive + data-intensive własne

Powiązane Tematy

• CWASI (Marcelino & Nastic 2025) — inter-function communication w edge-cloud
• Besozzi 2025 (Wasm vs unikernels)
• Colosi 2025 (Wasm workflows browser/edge/cloud)
• De Macedo 2022 (Wasm vs JS energia — poprzedni krok)
• Gap: Lumos NIE mierzy energii — możliwe rozszerzenie (#JE-4)

Notatki