Architektura i Eksperymenty

Ostatnia aktualizacja: 2026-05-27

Architektura systemu

Opis ogólny

System pomiarowy do rygorystycznej analizy energetycznej środowisk uruchomieniowych JavaScript (Node.js, Deno, Bun) w workloadach serverless. Główny wkład techniczny: standaryzowana metodologia uwzględniająca JIT warm-up i GC pauses (luka w literaturze), pierwsza porównawcza analiza energetyczna Node.js/Deno/Bun, oraz wielokryterialny model decyzyjny energia–latencja–koszt.

Komponenty główne

Komponent	Opis	Technologia
M1 – Workload Suite	6 kategorii workloadów (CPU, I/O, SSR, cold start, memory, mixed)	Node.js/Deno/Bun skrypty
M2 – Energy Measurement	Process-level energy attribution via RAPL + PowerJoular	Intel RAPL, PowerJoular
M3 – JIT Warm-up Protocol	Automatyczne odrzucanie N iteracji warm-up; Ljung-Box stationarity test	Python orchestrator
M4 – GC Profiler	Detekcja i filtrowanie GC pause spikes z energy trace	V8/JSC GC hooks
M5 – Statistical Analyzer	Median/IQR, Mann-Whitney U, Kruskal-Wallis, effect size	R / Python scipy
M6 – Decision Model	TOPSIS multi-criteria (energia × latencja × koszt)	Python topsis

Przepływ danych

flowchart TD
    WD([Workload definition]) --> M1[M1 Workload Suite\n6 categories × 3 runtimes]
    M1 --> BM[Bare-metal server\nUbuntu 24.04, Intel]
    BM --> M2[M2 RAPL + PowerJoular\nprocess-level energy]
    M2 --> M3[M3 JIT Warm-up Protocol\nodrzuć pierwsze N iteracji]
    M3 --> M4[M4 GC Profiler\nwykryj i filtruj GC spikes]
    M4 --> RAW([Raw energy + time series\n30 pomiarów per runtime × workload])
    RAW --> M5[M5 Statistical Analyzer\nmedian, IQR, Mann-Whitney U]
    M5 --> STATS([Wyniki statystyczne\np-values, effect sizes])
    STATS --> M6[M6 TOPSIS Decision Model\nenergia × latencja × koszt]
    M6 --> RANK([Ranking: runtime × workload × platform])

Stack technologiczny

Warstwa	Technologia	Uzasadnienie
Runtimes	Node.js 22 LTS, Deno 2.x, Bun 1.x	obiekty badania
Pomiar energii	Intel RAPL (perf stat), PowerJoular	process-level attribution
Środowisko	bare-metal Intel server, Ubuntu 24.04	eliminacja hypervisor noise
Orchestracja	Python 3.11 + subprocess	automatyzacja 30 powtórzeń
Statystyki	scipy.stats, R (lawstat)	Mann-Whitney U, Ljung-Box
Model decyzyjny	topsis-python	TOPSIS MCDM
Dane	własne pomiary benchmark	brak zewnętrznych datasets

Eksperymenty

JE-EXP-1: Energia Node.js vs Deno vs Bun — 6 Kategorii Workloadów

Status: planned Priorytet: high Powiązany pomysł: JE-1 Dodano: 2026-05-27

Hipoteza: Bun zużywa istotnie mniej energii niż Node.js dla CPU-bound workloadów (JavaScriptCore < V8 dla synchronicznej egzekucji JS), podczas gdy dla async I/O Deno jest energetycznie zbliżony lub lepszy niż Node.js (Tokio runtime). Nie istnieje runtime “zawsze najlepszy” dla wszystkich kategorii workloadów.

Dane:

Dataset: własne pomiary (brak zewnętrznych)
Podział: 30 powtórzeń per (runtime × workload × kategoria); 5 warm-up odrzucanych
Preprocessing: odfiltrowanie outlierów GC (IQR × 1.5), normalizacja do J/request

Metoda:

Przygotowanie workload suite: sortowanie (CPU), SHA256 hashing (CPU), JSON parse/stringify (CPU), file I/O (I/O), HTTP fetch (I/O), SQLite queries (I/O), SSR Handlebars (mixed), cold start to first response, large array ops (memory)
Kontrola środowiska: bare-metal Intel server, CPU governor=performance, izolacja na dedykowanym core
Pomiar: PowerJoular process-level (RAPL PACKAGE + DRAM) + wall clock time + RSS memory
Protokół: perf stat -e power/energy-pkg/ zsynchronizowany z PowerJoular; warm-up 5 iteracji odrzucanych
Stacjonarność: Ljung-Box test na energy time series (p>0.05 = stacjonarny)
Statystyki: median ± IQR, Mann-Whitney U dla każdej pary (Bun vs Node.js, Deno vs Node.js)

Modele / Baseline:

Model	Opis
Node.js 22 LTS	reference baseline
Deno 2.x	Rust/Tokio async
Bun 1.x	JavaScriptCore, szybki startup

Metryki:

Główna: energia [J/request] i czas [ms/request] per (runtime × workload)
Dodatkowe: RSS memory [MB], cold start energia [J], effect size (Cohen’s d)
Test statystyczny: Mann-Whitney U (α=0.05), Kruskal-Wallis dla 3 grup

Wyniki: (do wypełnienia po wykonaniu)

Workload	Node.js [J]	Deno [J]	Bun [J]	p-value (Bun vs Node)

Wnioski: (do wypełnienia po wykonaniu)

JE-EXP-2: Standaryzacja Metodologii Pomiaru Energii JS Runtimeów

Status: planned Priorytet: high Powiązany pomysł: JE-3 Dodano: 2026-05-27

Hipoteza: JIT warm-up w Node.js/Deno (V8) wymaga co najmniej 10-15 iteracji przed stabilizacją zużycia energii (Ljung-Box p>0.05 po N iteracjach), a GC-driven energy spikes mają wpływ >5% na medianę energii bez filtrowania — co uzasadnia dedykowany protokół warm-up+GC dla JS energy benchmarking.

Dane:

Dataset: własne pomiary energia vs iteracja (N=100 powtórzeń per runtime, CPU-bound workload)
Podział: szereg czasowy energii [J] per iteracja
Preprocessing: brak (surowe pomiary RAPL)

Metoda:

Pomiar 100 kolejnych wywołań workloadu SHA256 per runtime (bez restartu procesu)
Zapis energii [J] per wywołanie → szereg czasowy E(t)
Ljung-Box test na autocorrelation: kiedy seria staje się stacjonarna? (→ minimalne N warm-up)
Detekcja GC spikes: identyfikacja wartości odstających (IQR × 1.5) → oblicz % wpływu na medianę
Porównanie metod pomiaru: RAPL via perf stat vs PowerJoular vs szacowanie CPU-seconds×TDP
Walidacja cross-method: korelacja Pearsona (RAPL vs PowerJoular, oczekiwane R²>0.95)
Rezultat: protokół eksperymentalny (PDF + repozytorium GitHub)

Modele / Baseline:

Model	Opis
Bez warm-up (N=0)	standard naive approach
N=5 warm-up	konwencja z literatury
N=10 warm-up	hipoteza: minimum dla V8
N=15 warm-up	konserwatywny

Metryki:

Główna: minimalne N warm-up dla stacjonarności (próg: Ljung-Box p>0.05)
Dodatkowe: % wpływ GC spikes na medianę, R² (RAPL vs PowerJoular)
Test statystyczny: Ljung-Box (α=0.05), Pearson R²

Wyniki: (do wypełnienia po wykonaniu)

Runtime	Min warm-up N	GC spike impact [%]	RAPL vs PJ R²

Wnioski: (do wypełnienia po wykonaniu)

JE-EXP-3: Model Decyzyjny TOPSIS — Energia × Latencja × Koszt dla Runtime Selection

Status: planned Priorytet: high Powiązany pomysł: JE-2 Dodano: 2026-05-27

Hipoteza: Model TOPSIS z wagami energia:latencja:koszt = 0.5:0.3:0.2 rekomenduje inny runtime niż model oparty wyłącznie na latencji w co najmniej 30% kombinacji (workload × platforma) — wykazując, że optymalizacja bez wymiaru energetycznego prowadzi do suboptimalnych wyborów z perspektywy sustainability.

Dane:

Dataset: wyniki z JE-EXP-1 + dodatkowe pomiary na AWS Lambda i Cloudflare Workers
Podział: przestrzeń decyzyjna: 3 runtimes × 3 platformy × 6 workload kategorii × 2 stany (cold/warm)
Preprocessing: normalizacja metryk do [0,1] dla TOPSIS

Metoda:

Uzupełnienie danych: pomiary na AWS Lambda (Node.js, Deno-layer) + Cloudflare Workers (Node.js compat)
Implementacja TOPSIS: 4 metryki: E [J/req], latencja_p50 [ms], cold_start [ms], koszt [$/M req]
Analiza wrażliwości: jak zmiana wag (energia ∈ [0.1, 0.9]) zmienia ranking runtimów?
Porównanie: TOPSIS(energy) vs TOPSIS(latency-only) — ile przypadków daje inny wybór?
Walidacja: 5 case studies (Next.js SSR, REST API, edge middleware, background job, streaming)

Modele / Baseline:

Model	Opis
Latency-only ranking	konwencjonalne podejście
TOPSIS (energy only)	optymalizacja energy
TOPSIS (energy:lat:cost = 0.5:0.3:0.2)	proponowany model
TOPSIS (equal weights)	neutralny punkt odniesienia

Metryki:

Główna: % przypadków gdzie TOPSIS(energy) ≠ latency-only (próg: >30%)
Dodatkowe: carbon footprint [gCO₂/req], sensitivity index wag, Kendall tau (ranking stabilność)
Test statystyczny: McNemar test (proporcja różnych rekomendacji, α=0.05)

Wyniki: (do wypełnienia po wykonaniu)

Wagi energii	% różnych rekomendacji	Preferowany runtime CPU-bound	Preferowany runtime I/O-bound

Wnioski: (do wypełnienia po wykonaniu)

Pipeline danych

Brak zewnętrznych datasets — wszystkie dane generowane własnym benchmark suite. Środowisko pomiarowe: dedykowany bare-metal serwer Intel (Ubuntu 24.04, CPU governor=performance, wyłączony turbo boost dla reprodukowalności). PowerJoular zbiera energię procesu w 1-sekundowych interwałach. Orchestrator Python uruchamia każdy workload 30+5 razy i zbiera pary (czas, energia, pamięć).

Wymagania techniczne

Środowisko

Python: 3.11+
OS: Ubuntu 24.04 (bare-metal, Intel CPU z RAPL support)
Node.js: 22 LTS
Deno: 2.x
Bun: 1.x
RAM: min. 8 GB (workloady memory-intensive)

Kluczowe biblioteki

# requirements-research.txt
powerjoular>=0.7     # process-level energy measurement
scipy>=1.11          # Mann-Whitney, Ljung-Box
statsmodels>=0.14    # time series tests
pandas>=2.0
topsis-python>=1.1   # MCDM decision model

# npm packages (workload scripts)
# bun/deno: native

Status eksperymentów

ID	Tytuł	Status	Priorytet	ETA	Wynik
JE-EXP-1	Energia Node.js vs Deno vs Bun — 6 workloadów	planned	high	—	—
JE-EXP-2	Standaryzacja metodologii pomiaru energii JS	planned	high	—	—
JE-EXP-3	TOPSIS model decyzyjny energia×latencja×koszt	planned	high	—	—

Research

Przeglądaj

Architektura i Eksperymenty

Architektura i Eksperymenty

Architektura systemu

Opis ogólny

Komponenty główne

Przepływ danych

Stack technologiczny

Eksperymenty

JE-EXP-1: Energia Node.js vs Deno vs Bun — 6 Kategorii Workloadów

JE-EXP-2: Standaryzacja Metodologii Pomiaru Energii JS Runtimeów

JE-EXP-3: Model Decyzyjny TOPSIS — Energia × Latencja × Koszt dla Runtime Selection

Pipeline danych

Wymagania techniczne

Środowisko

Kluczowe biblioteki

Status eksperymentów

Graf

Spis treści