Research

Energetyczna Efektywność Środowisk Uruchomieniowych JavaScript

7 min. czytania

Energetyczna Efektywność Środowisk Uruchomieniowych JavaScript

Opis projektu

Badania nad efektywnością energetyczną współczesnych środowisk uruchomieniowych JavaScript (Node.js, Deno, Bun, WinterJS, edge runtimes) w kontekście architektur serverless i edge computing. Skupia się na rygorystycznej metodologii pomiarowej zużycia energii oraz budowie modelu decyzyjnego dla inżynierów dobierających runtime do workloadów.

JavaScript w środowiskach serverless — kontekst

Dlaczego JavaScript dominuje w serverless?

JavaScript i Node.js stały się de facto standardem dla funkcji serverless z kilku powodów strukturalnych:

1. Model wykonania dopasowany do serverless Architektura event-loop Node.js (single-threaded, non-blocking I/O) jest naturalna dla wzorca FaaS: krótkie, reaktywne wykonania z dużą ilością operacji I/O (HTTP call, zapis do bazy, kolejka). W przeciwieństwie do języków wielowątkowych (Java, Go), Node.js nie tworzy nowego wątku per request — co redukuje overhead izolacji i zużycie pamięci na zimny start.

2. Dominacja rynkowa Według State of JavaScript 2024: Node.js używa 90.8% programistów JS, Bun 16.4%, Deno 11.8%. AWS Lambda, Google Cloud Functions i Azure Functions obsługują Node.js jako pierwszy lub jedyny język z natywnym SDK. JavaScript jest najczęściej używanym językiem w funkcjach serverless komercyjnych platform (AWS, Cloudflare, Vercel).

3. Ekosystem npm Rejestr npm (~3 mln pakietów) jest największym repozytosystem pakietów w historii. Funkcja serverless może wciągnąć dowolną bibliotekę bez dodatkowej konfiguracji środowiska — co jest kluczowe dla szybkości wdrożenia, ale generuje pytanie o koszt energetyczny zależności.

4. Cold start advantage Node.js (V8 JIT) ma krótszy cold start niż JVM-based (Java/Kotlin: 500ms–2s) i kompilowane-statycznie (C#/.NET: 300ms–1s). Jest porównywalny z Go/Rust (które nie mają GC pause), ale Go wymaga kompilacji. V8 Isolates (Cloudflare Workers) eliminują problem cold start niemal całkowicie (<1ms) przez reużywanie silnika JS — technologia niedostępna dla innych języków.

5. Nowy ekosystem runtimeów: Node.js → Deno → Bun → WinterJS 2009: Node.js (Ryan Dahl, V8) — libuv, CommonJS, npm 2020: Deno (Ryan Dahl, V8) — TypeScript natywny, Web APIs, permissions model, bez npm 2022: Bun (Jarred Sumner, JavaScriptCore) — 3× szybszy install, JSC zamiast V8, natywne TypeScript 2023: WinterJS (Wasmer, SpiderMonkey) — Wasm-first, WinterCG-compliant, dla edge WASM deploymentu

6. V8 Isolates jako przełom architektoniczny Cloudflare Workers (2017) zrewolucjonizował serverless przez izolację na poziomie silnika JS zamiast OS. Jeden proces V8 hostuje tysiące Isolates (osobne contexty JS, osobne heapy). Cold start <1ms vs 125ms Firecracker MicroVM. Konsekwencja: JS jest jedynym językiem, który może korzystać z tej formy izolacji natywnie — inne języki wymagają transpilacji do WASM lub osobnego procesu.

Kluczowe różnice między runtimeami

RuntimeSilnik JSCold start (bare)Model izolacjiWinterCG
Node.js 24V8~50-300msprocess/forkCzęściowy
Deno 2V8~30-150msprocess/forkPełny
Bun 1.xJavaScriptCore~10-50msprocess/forkCzęściowy
WinterJSSpiderMonkeyTBDWASM sandboxPełny
Cloudflare WorkersV8 Isolates<1msV8 IsolatePełny
Vercel EdgeV8 Isolates<1msV8 IsolatePełny

Gap: brak wymiaru energetycznego

Wszystkie powyższe różnice (cold start, throughput, izolacja) są zmierzone wyłącznie w czasie i pamięci. Nikt nie zmierzył:

  • Ile energii RAPL zużywa Node.js vs Bun dla identycznego workloadu HTTP API?
  • Czy krótszy cold start Bun = mniej energii per invocation?
  • Jaki jest energetyczny overhead V8 Isolates vs process isolation dla JS?
  • Czy JavaScriptCore (Bun) jest energetycznie efektywniejszy od V8 (Node.js/Deno)?

To jest główna motywacja projektu JE.

Pytania badawcze

  1. Jak mierzyć zużycie energii przez JS runtimes w sposób powtarzalny i porównywalny?
  2. Czy Deno/Bun są energetycznie efektywniejsze od Node.js dla typowych serverless workloadów?
  3. Jakie cechy workloadu (CPU-bound, I/O-bound, memory-bound) determinują wybór runtimes?
  4. Jak edge runtimes (Cloudflare Workers, Vercel Edge) różnią się energetycznie od tradycyjnych serverless?
  5. Jak zbudować praktyczny model decyzyjny dla architektów wybierających runtime?
  6. Jaki jest energetyczny koszt mechanizmu izolacji (kontener vs MicroVM vs V8 Isolates vs WASM sandbox) dla JS workloadów?
  7. Czy możliwe jest zaprojektowanie nowego środowiska uruchomieniowego JS zoptymalizowanego pod kątem energy-delay product (EDP) dla deploymentu serverless, z energy-aware JIT tiering i WinterCG compliance?

Kluczowe publikacje (with-pdf)

Node.js / Deno / Bun benchmarks

  • laakso-js-runtimes-2025 — The Next Generation of Server-Side JavaScript Runtimes (Bachelor’s thesis, Turku AMK 2025) — benchmark data: Bun 103k req/s vs Node.js 73k vs Deno 73k (native); JavaScriptCore vs V8 performance gap; brak energii = gap badawczy JE-1

Narzędzia pomiarowe

  • noureddine-powerjoular-2022 — PowerJoular and JoularJX: Multi-Platform Software Power Monitoring Tools — 44 cytowania — per-process RAPL + Raspberry Pi ARM support — narzędzie JE-3

WebAssembly + edge/serverless

Carbon-aware serverless

Cold start i serverless performance

Referencje (do przeczytania)

Fundamenty — energia i języki programowania

WebAssembly vs JavaScript

Node.js / Deno / Bun

Metodologia eksperymentalna

Kluczowe publikacje (references — architektura serverless)

Modele izolacji

  • agache-firecracker-serverless-2020 — Firecracker MicroVM (NSDI 2020) — 600+ cytowań — baseline dla analizy kosztu izolacji; 125ms cold start, 5MB overhead/funkcja
  • shillaker-faasm-serverless-2020 — Faasm: WASM isolation dla stateful serverless (ATC 2020) — 10× szybszy cold start niż Docker; WASM jako mechanizm izolacji bez OS overhead
  • boucher-sledge-wasm-edge-2020 — Sledge: WASM edge serverless runtime (Middleware 2020) — cooperative scheduler, ARM edge
  • jangda-wasm-performance-2019 — Not So Fast: WASM vs native (ATC 2019) — WASM 1.55× wolniejszy średnio; analiza źródeł overhead

Datasety / Benchmarki

  • Computer Language Benchmarks Game (CLBG) — repozytorium benchmarków (używane przez Pereira et al.)
  • Własne pomiary energii: RAPL (Intel), perf, PowerJoular, JoularJX, Kepler
  • Benchmarki obciążeniowe: wrk2, k6, Artillery, autocannon, FunctionBench
  • Platformy edge: Cloudflare Workers (V8 Isolates), Vercel Edge, Fastly Compute@Edge (WASM), Deno Deploy
  • Platformy serverless open-source: OpenFaaS, KNative, OpenWhisk — dla reprodukowalnych eksperymentów

Architektura środowisk serverless — kontekst

Modele izolacji (od najbardziej do najmniej izolowanego)

ModelPrzykładCold startOverhead memMechanizm
VM pełnaAWS EC2 Lambda Gen1>1s~512MBKVM + pełny OS
MicroVMFirecracker (Lambda Gen2)~125ms~5MBKVM + stripped kernel
KontenerDocker + gVisor~50-100ms~20-50MBseccomp + namespaces
WASM sandboxFaasm, Sledge, Spin~1-10ms~1-5MBWASM linear memory
V8 IsolateCloudflare Workers<1ms~128KBJS engine heap isolation
ProcessNode.js bare~50-300ms~30-80MBfork/exec

Kluczowy gap badawczy: żaden z tych modeli nie ma zmierzonego energetycznego kosztu izolacji per request dla JS workloadów.

WinterCG — Web-interoperable Runtimes Community Group

Standard W3C Community Group (2022) definiujący wspólne API dla JS runtimes poza przeglądarką:

  • Fetch API, Streams, URL, SubtleCrypto, TextEncoder — standardowe interfejsy
  • Implementacje: Deno, Cloudflare Workers, Vercel Edge, Bun (częściowo), WinterJS (SpiderMonkey)
  • Gap: brak energy/power primitives w standardzie — propozycja JE-16

Warstwy nowego środowiska uruchomieniowego (propozycja JE-15)

┌─────────────────────────────────────────────────────────┐
│              JS/WASM Function Code                      │
├─────────────────────────────────────────────────────────┤
│          WinterCG-compliant APIs                        │
│   (Fetch, Streams, SubtleCrypto, navigator.energy*)     │
├─────────────────────────────────────────────────────────┤
│         Energy-aware JIT Tiering                        │
│   Tier 0: Interpret │ Tier 1: Baseline │ Tier 2: Opt.  │
│   selection based on: invocation freq × energy budget   │
├─────────────────────────────────────────────────────────┤
│    V8 Isolates runtime (shared heap, isolated contexts) │
│    or JavaScriptCore (Bun model)                        │
├─────────────────────────────────────────────────────────┤
│         Energy Attribution Layer                        │
│   RAPL hardware counters + per-isolate software model   │
├─────────────────────────────────────────────────────────┤
│    WASI system interface (portable system calls)        │
└─────────────────────────────────────────────────────────┘

*navigator.energy — propozycja rozszerzenia WinterCG (#JE-16)

Aktywne kierunki badań

  1. Metodologia pomiarowa — standaryzacja pomiaru energii JS runtimes (#JE-1, JE-3)
  2. Benchmark workloadów — typowe wzorce serverless (HTTP API, SSR, stream, edge functions) (#JE-8)
  3. Model decyzyjny — kiedy Bun/Deno zamiast Node.js? edge zamiast serverless? (#JE-2)
  4. Ekologiczny aspekt — zielone chmury, carbon footprint JS ecosystem (#JE-5, JE-7)
  5. Koszt izolacji — energetyczny overhead mechanizmów izolacji dla JS workloadów (#JE-14)
  6. Nowy runtime — projekt energy-first JS runtime z energy-aware JIT tiering (#JE-15)
  7. WinterCG energy API — propozycja rozszerzenia standardu o energy attribution (#JE-16)

Venue docelowe

Tagi wyszukiwania

#energy-efficiency #javascript #serverless #edge-computing #runtime #benchmark #green-software

Prefix ID

#JE-

Elementów w folderze: 9.