Metodologia

Przegląd Podejścia

Badanie przyjmuje podejście empiryczne oparte na kontrolowanym eksperymencie porównawczym, wzorowane na metodologii Pereira et al.¹² (RAPL + standaryzowane benchmarki) oraz wielowymiarowym projekcie Albonico et al.³ (język $\times$ workload $\times$ konfiguracja). Uzupełniamy je o siedmiowymiarową przestrzeń kontroli zmiennych CLUE~⁴ (runtime, hardware, obciążenie, stan systemu, czas, granularność pomiaru, kontekst wdrożenia). Całość realizowana jest w czterech fazach:

• Faza M1 — Standaryzacja pomiaru (Eksperyment [→]): opracowanie protokołu warm-up JIT i filtrowania GC dla pomiarów energetycznych JS.
• Faza M2 — Porównanie empiryczne (Eksperymenty [→], [→], [→]): pomiar energii Node.js, Deno iBun dla 6kategorii workloadów serverless; analiza amortyzacji JIT i~wyznaczenie parametrów keep-alive.
• Faza M3 — Model decyzyjny (Eksperyment [→]): budowa wielokryterialnego rankingu TOPSIS i analiza wrażliwości wag.
• Faza M4 — Walidacja cross-platform (Eksperyment [→]): replikacja pomiarów na drugiej platformie x86-64 w celu weryfikacji generalizowalności rankingów.

Wybór metody RAPL (Running Average Power Limit) i PowerJoular jako narzędzi pomiarowych uzasadniamy ich zwalidowaną dokładnością (do 1% błędu względnego vs miernik sprzętowy)~⁵ oraz możliwością atrybucji energii do procesu, co jest kluczowe przy porównaniu odizolowanych środowisk uruchomieniowych.

Środowisko Eksperymentalne

Wszystkie eksperymenty przeprowadzone są na dedykowanym serwerze bare-metal, eliminując szum introdukowany przez hiperwizor (do 15% wariancji wg Werner et al.~⁴).

\centering Środowisko eksperymentalne — dwie platformy bare-metal

---

| Komponent | P1 (Skylake) | P2 (Coffee Lake) |

| CPU | Intel Core i7-6700, 4C/8T, 65,W TDP | Intel Xeon E-2176G, 6C/12T, 80,W TDP | | Mikroarchitektura | Skylake (6. gen., 2015) | Coffee Lake (8. gen., 2018) | | RAM | 64,GB DDR4 | 64,GB DDR4 ECC | | Storage | 2,$\times$,512,GB NVMe SSD | 2,$\times$,960,GB NVMe U.2 SSD | | OS | Ubuntu 24.04.4, kernel 6.8 | Ubuntu 24.04.3, kernel 6.8 | | Domeny RAPL | Package, PP0 Core, Uncore | Package, PP0 Core, Uncore, DRAM |

3{l}{Wspólne dla obu platform:} \

| Dostawca | 2{l}{Hetzner dedicated server (bare-metal), bez hiperwizora} | | Node.js | 2{l}{v24.15.0 (V8)} | | Deno | 2{l}{2.8.1 (V8 + Tokio/Rust)} | | Bun | 2{l}{1.3.14 (JavaScriptCore/WebKit)} | | Pomiar energii | 2{l}{Intel RAPL sysfs (/sys/class/powercap/intel-rapl:0/energy_uj)} | | Turbo Boost | 2{l}{wyłączony (no_turbo = 1)} | | CPU Governor | 2{l}{performance (stała częstotliwość taktowania)} | | Chłodzenie | 2{l}{30,s przerwy między workloadami} | | Powtórzenia | 2{l}{50 pomiarów właściwych + $N_{warm-up}$ (ustalone w EXP-2)} |

Wybór serwerów bare-metal (bez hiperwizora) eliminuje zakłócenia pomiarów RAPL introdukowane przez wirtualizację (do 15% wariancji wg Werner et al.~⁴). Dwie mikroarchitektury umożliwiają walidację stabilności rankingów między mikroarchitekturami x86-64. Platforma P2 eksponuje dodatkowo domenę RAPL DRAM, niedostępną na P1. Turbo Boost jest wyłączony na obu platformach, aby zapewnić deterministyczną częstotliwość taktowania. CPU Governor performance utrzymuje stałe taktowanie przez cały czas eksperymentu. Między kolejnymi workloadami stosujemy 30-sekundowy okres chłodzenia, aby uniknąć throttlingu termicznego.

Workloady

Zdefiniowano 6 kategorii workloadów reprezentujących typowe wzorce funkcji serverless:

\centering Kategorie workloadów i ich charakterystyka

---

| Kategoria | Reprezentatywne zadanie | Dominująca cecha |

| CPU-bound | Sortowanie, SHA-256 hashing, JSON parse/stringify | obliczeniowa | | I/O-bound | Odczyt/zapis pliku, HTTP fetch, SQLite queries | we/wy | | SSR | Renderowanie szablonu (Handlebars, EJS) | mieszana | | Cold start | Spawn procesu $\to$ pierwsze żądanie HTTP | inicjalizacja | | Memory-heavy | Operacje na dużych tablicach/obiektach (\textgreater100,MB) | pamięciowa | | Mixed (REST) | JSON in $\to$ compute $\to$ JSON out (typowy handler API) | mieszana |

Implementacje workloadów są identyczne funkcjonalnie we wszystkich trzech runtimeach (Node.js, Deno, Bun), korzystając wyłącznie z API objętych specyfikacją WinterTC (Fetch, Streams, URL, SubtleCrypto, TextEncoder), co zapewnia porównywalność wyników. Kod workloadów jest publicznie dostępny jako benchmark suite (GitHub, MIT).

Metryki Ewaluacji

Energia całkowita per żądanie. Główna metryka: energia zużyta przez proces runtimes w przeliczeniu na jedno żądanie, mierzona przez Intel RAPL (PACKAGE + DRAM domains):

$$E_{req}=\frac{{\int }_{t_0}^{t_1}P(t)dt}{N_{req}}[J/request]$$

gdzie $P(t)$ to chwilowa moc procesu [W], $t_0$ i $t_1$ — czas rozpoczęcia i zakończenia serii pomiarowej, $N_{req}$ — liczba żądań w serii.

Energia zimnego startu. Energia inicjalizacji środowiska uruchomieniowego:

$$E_{cold}={\int }_0^{T_{cold}}P(t)dt[J]$$

gdzie $T_{cold}$ to czas od spawnu procesu do pierwszej odpowiedzi HTTP.

Energy-Delay Product. Złożona metryka balansująca energię i czas wykonania:

$$EDP=E_{req}\times T_{req}[J\cdots ]$$

Latencja p50. Mediana czasu odpowiedzi [ms/request], mierzona wrk2 dla scenariuszy HTTP.

Zużycie pamięci. RSS (Resident Set Size) [MB] pobierany z /proc/[pid]/status.

Metody Bazowe

Jako punkty odniesienia przyjmujemy:

• Latency-only ranking~⁶⁷: konwencjonalne podejście optymalizujące wyłącznie czas wykonania — bez wymiaru energetycznego. Stanowi baseline dla modelu TOPSIS.
• Node.js 24 LTS (v24.15.0): dominujące środowisko uruchomieniowe serverless, punkt odniesienia dla normalizacji wyników.
• Protokół bez warm-up (N=0)~¹: standardowe podejście z literatury, ignorujące JIT warm-up — stosowane jako baseline do wykazania wpływu protokołu standaryzacyjnego (#JE-EXP-2).

Procedura Eksperymentalna

Eksperyment JE-EXP-2: Protokół Warm-up JIT i Filtrowanie GC

Hipoteza: JIT warm-up w Node.js/Deno wymaga co najmniej 10–15 iteracji przed stabilizacją energetyczną (test Ljung-Box $p>0.05$), a skoki GC wpływają o ponad 5% na medianę energii bez filtrowania.

• Rejestracja 100 kolejnych wywołań workloadu SHA-256 per runtime (bez restartu procesu), pomiar energii [J] per wywołanie.
• Test Ljung-Box na autokorelację szeregu energetycznego: identyfikacja minimalnego $N_{warm-up}$, po którym seria staje się stacjonarna ($p>0.05$).
• Detekcja skoków GC: wartości $>Q_3+1,5\cdot IQR$ w szeregu energetycznym. Obliczenie procentowego wpływu skoków GC na medianę energii bez filtrowania.
• Walidacja metody pomiarowej: korelacja Pearsona między RAPL (perf stat) a PowerJoular (oczekiwane $R^2>0,95$).
• Wynik: protokół warm-up ($N_{warm-up}$, filtrowanie GC) stosowany we wszystkich pozostałych eksperymentach.

Eksperyment JE-EXP-1: Porównanie Energetyczne Node.js, Deno, Bun

Hipoteza (H1): Bun zużywa istotnie mniej energii niż Node.js dla workloadów CPU-bound (JavaScriptCore vs V8). Hipoteza (H2): Dla asynchronicznych zadań I/O-bound Deno jest energetycznie zbliżony do Node.js. Hipoteza (H5): Nie istnieje środowisko uruchomieniowe dominujące we wszystkich kategoriach workloadów.

• Uruchomienie każdego z 6 workloadów (Tabela~[→]) dla każdego z 3 runtimeów: Node.js 22, Deno 2.x, Bun 1.x. Łącznie: 18 konfiguracji pomiarowych.
• Zastosowanie protokołu z JE-EXP-2: odrzucenie 5 iteracji warm-up (lub $N_{warm-up}$ jeśli większe), filtrowanie skoków GC.
• Pomiar 50 iteracji właściwych per konfiguracja. Łącznie $\ge 900$ pomiarów.
• Statystyki opisowe: mediana $\pm$ IQR dla energii [J/req], latencji [ms/req], RSS [MB].
• Testy istotności: Mann-Whitney U dla par (Bun vs Node.js, Deno vs Node.js) per workload ($\alpha =0,05$). Kruskal-Wallis dla porównania 3 grup.
• Miary efektu: $d$ Cohena dla istotnych par (interpretacja: mały $|d|<0,5$, średni $0,5\le |d|<0,8$, duży $|d|\ge 0,8$).
• Wizualizacja: wykresy pudełkowe (boxplot) energii per (runtime $\times$ workload).

Eksperyment JE-EXP-3: Model Decyzyjny TOPSIS

Hipoteza: Model TOPSIS z wagami energia:latencja:koszt = 0{,}5:0{,}3:0{,}2 rekomenduje inny runtime niż podejście latency-only w co najmniej 30% kategorii workloadów, co dowodzi, że optymalizacja bez wymiaru energetycznego prowadzi do suboptymalnych wyborów z perspektywy zrównoważonego oprogramowania.

• Dane wejściowe: macierz wyników z JE-EXP-1 — mediana energii [J/req], latencji [ms/req] i szacunkowego kosztu operacyjnego [$/Mreq]dlaka\dot{z}dejpary(runtime$\times$workload).Kosztszacowanyjako$C = T_{req} \cdot c_{GB-s}$,gdzie$c_{GB-s}$tocenazaGB-sekundęnaAWSLambda($0{,}0000166667).
• Normalizacja metryk do $[0,1]$: min-max dla wszystkich trzech kryteriów (wszystkie traktowane jako koszty minimalizowane).
• Implementacja TOPSIS z 3 kryteriami: energia $E_{req}$[J/req], latencja $T$[ms/req], koszt $C$~[$/Mreq],wagi$w_E = 0{,}5$,$w_T = 0{,}3$,$w_C = 0{,}2$.
• Analiza wrażliwości: waga energii $w_E\in 0,1,0,2,...,0,9$ (przy zachowaniu proporcji $w_T:w_C=3:2$). Identyfikacja, dla jakich $w_E$ zmienia się top-1 runtime per workload.
• Porównanie TOPSIS vs latency-only dla 6 workloadów: test McNemara (proporcja różnych rekomendacji, $\alpha =0,05$).

EXP-3 nie wymaga nowych pomiarów — jest analizą post-hoc na danych z JE-EXP-1, uruchamianą automatycznie przez skrypt analysis/topsis_model.py.

Eksperyment JE-EXP-6: Walidacja Cross-Platform

Hipoteza: Rankingi energetyczne uzyskane na P1 (Intel Core i7-6700, Skylake, 65W TDP) są stabilne na drugiej platformie x86-64 (P2: Intel Xeon E-2176G, Coffee Lake, 80W TDP) — tj. kolejność runtimeów per workload jest identyczna na obu platformach.

• Powtórzenie eksperymentu JE-EXP-1 w całości na platformie P2, przy użyciu identycznych wersji runtimeów, skryptów workloadowych i parametrów protokołu (N_warm-up = 30, filtrowanie GC, n = 50 powtórzeń per konfiguracja).
• Dodatkowy pomiar domeny RAPL DRAM (intel-rapl:0:2), dostępnej na P2 lecz nieeksponowanej przez i7-6700 na P1.
• Obliczenie rankingów energetycznych per workload na P2 i porównanie z rankingami P1. Kryterium sukcesu: co najmniej 5 z 6 workloadów z identyczną kolejnością runtimeów.
• Analiza proporcji między runtimeami: sprawdzenie, czy różnica względna (np. Bun vs Node.js przy I/O-bound) różni się o mniej niż 5 p.p. między platformami.
• Analiza udziału domeny DRAM w energii pakietu CPU per workload na P2.

Zagrożenia dla Trafności

Klasyfikacja według Wohlin et al. (trafność wewnętrzna, zewnętrzna, konstruktu):

Trafność wewnętrzna (internal validity). Główne zagrożenie stanowi niestabilność pomiaru energii: skoki GC, JIT warm-up i aktywność tła systemu mogą wprowadzić szum. Środki zaradcze: protokół warm-up z testem Ljung-Box (Eksperyment [→]), filtrowanie skoków GC (IQR $\times$ 1{,}5), izolacja CPU (taskset, turbo boost off), 30-sekundowy czas chłodzenia między seriami. Drugie zagrożenie: nieidentyczne wersje bibliotek między runtimeami. Mitygacja: używamy wyłącznie standardowych API (WinterTC) bez zewnętrznych zależności npm.

Trafność zewnętrzna (external validity). Eksperymenty przeprowadzono na dwóch platformach sprzętowych x86-64: P1 (Intel Core i7-6700, Skylake, 2015, TDP65W) iP2 (Intel Xeon E-2176G, Coffee Lake, 2018, TDP80W). Wartości bezwzględne energii [J] różnią się między platformami proporcjonalnie do TDP; natomiast rankingi względne między runtimeami są w 100% stabilne (6/6 workloadów — Sekcja[→]), co potwierdza generalizowalność wyników na klasy platform x86-64 server-grade. Wyniki mogą być nieprzenoszalne na sprzęt ARM (Ampere Altra, Apple Silicon), gdzie hierarchia energetyczna V8 vs JavaScriptCore może być odmienna ze względu na inną implementację pamięci podręcznej ibrak RAPL. Ponadto workloady benchmarkowe mogą nie w pełni odwzorowywać produkcyjne wzorce ruchu — mitygacja przez workload “mixed REST” wzorowany na statystykach ruchu AWS Lambda⁸.

Trafność konstruktu (construct validity). RAPL mierzy energię pakietu CPU i DRAM, nie uwzględniając sieci i dysków SSD — co zaniża całkowity koszt energetyczny workloadów I/O-bound. Raportujemy to ograniczenie explicite i uzupełniamy o pomiary czasu I/O. Miara J/request zakłada liniowość energii względem liczby żądań — co może nie zachodzić przy małych i dużych obciążeniach (JIT w małych N, saturacja CPU w dużych N). Dlatego normalizujemy wyłącznie dla steady-state (po stabilizacji JIT).

---

Bibliografia

Footnotes

1. Pereira et al. (2017). Energy Efficiency Across Programming Languages: How Do Energy, Time, and Memory Relate?. Proceedings of the 10th ACM SIGPLAN International Conference on Software Language Engineering (SLE 2017). ↩ ↩²

2. Pereira et al. (2021). Ranking Programming Languages by Energy Efficiency. Science of Computer Programming, vol. 205, pp. 102609. ↩

3. Albonico, Cannizza, Wortmann (2025). Energy Efficiency in ROS Communication: A Comparison Across Programming Languages and Workloads. Frontiers in Robotics and AI, vol. 12. ↩

4. Werner et al. (2025). A Comprehensive Experimentation Framework for Energy-Efficient Design of Cloud-Native Applications. arXiv:2503.08641 ↩ ↩² ↩³

5. Noureddine (2022). PowerJoular and JoularJX: Multi-Platform Software Power Monitoring Tools. Proceedings of the 18th International Conference on Intelligent Environments (IE 2022). ↩

6. Smirnov et al. (2024). A Comparative Analysis of the Performance of JavaScript Code Execution Environments: Node.js, Deno and Bun. Programming Systems and Computational Methods, pp. 109—123. ↩

7. Laakso (2025). The Next Generation of Server-Side JavaScript Runtimes: Node.js, Deno and Bun. Turku University of Applied Sciences. ↩

8. Li et al. (2019). Open-Source Serverless Platforms: Function Execution Environment Characterization and Optimization. Proceedings of the IEEE International Conference on Cloud Computing (CLOUD 2019). ↩