Jak mierzymy
Liczby, które ta strona podaje jako zmierzone, zmierzyliśmy na serwerach bare metal, z procesorem, którego używają nasze serwery produkcyjne: uśpienie, wybudzenie, migawkę i benchmark CPU. Oto każda z nich, z maszyną, datą, sposobem pomiaru i miejscem, gdzie leżą surowe wyniki.
- Bare metal. Cała fizyczna maszyna, a nie maszyna wirtualna na cudzej, więc nie dzieli jej z nami nic, czego nie widzimy.
- Mediany wraz z rozrzutem. Środkowa wartość z wielu przebiegów, a obok niej 95. percentyl i liczba przebiegów.
- Najlepszy przypadek nazywamy po imieniu. Większość pomiarów wykonaliśmy, gdy nic innego nie obciążało maszyny; tam, gdzie tak było, strona to zaznacza.
- Surowe wyniki zachowane. Przy każdej liczbie podajemy plik, z którego ją odczytano, w repozytorium razem z kodem, który ją wytworzył.
Uśpienie, wybudzenie i migawka
- Maszyna
- Cherry Servers, Singapur: AMD Ryzen 9 9950X (Zen 5, 16 rdzeni), 128 GB, Ubuntu 26.04.1, jądro 7.0.0-34
- Dzień
- 3 października 2026
- Piaskownica
- piaskownica 4 vCPU / 8 GiB, node:24-bookworm
- Węzeł
- sandboxd z ustawieniami domyślnymi z tamtego dnia: Firecracker z poprawkami, pamięć w dwóch warstwach, proces trzymany w gotowości dla każdej uśpionej piaskownicy, urządzenia na PCI
- Wywołujący
- na tej samej maszynie, przez jedno stale otwarte połączenie, więc wynik mierzy samo żądanie, a nie nawiązywanie połączenia
| Pomiar | Jak mierzony jest czas | Mediana | p95 | Przebiegi | Odczytano z |
|---|---|---|---|---|---|
| Uśpienie | POST …/sleep, z perspektywy wywołującego | 2.3 ms | 2.8 ms | 30 | wake.txt cycle sleep |
| Wybudzenie po samoczynnym zaśnięciu | czas przywracania według samego węzła (nagłówek Server-Timing), dla następnego wywołania | 3.5 ms | 3.9 ms | 29 | wake.txt auto wake |
| Odpowiedź na to wywołanie | całe żądanie, które ją wybudziło, od wysłania do odpowiedzi | 6.7 ms | 7.1 ms | 29 | wake.txt auto call |
| Wybudzenie tuż po uśpieniu | proces trzymany w gotowości do następnego wybudzenia jeszcze się uruchamia, więc wybudzenie czeka | 5.6 ms | 6.3 ms | 30 | wake.txt cycle wake |
| Migawka działającej piaskownicy | przez API: pamięć, procesy i dysk, w trakcie działania | 32 ms | — | 4 | snapshot.txt 31.5 to 31.9 ms |
| Utworzenie z puli | kopia szablonu, który już działa | 1.3 ms | — | 100 | tti-sequential.txt create median |
| Utworzenie aż do odpowiedzi na pierwsze polecenie | jedna po drugiej, sto razy | 11.0 ms | 12.0 ms | 100 | tti-sequential.txt sequential x100 |
| 30 naraz: wszystkie uśpione | trzydzieści piaskownic usypianych w tej samej chwili, do ostatniej | 49.0 ms | — | 1 | wake.txt concurrent 30 sleep_all |
| 30 naraz: wszystkie wybudzone | te same trzydzieści wybudzane w tej samej chwili, do ostatniej | 61.4 ms | — | 1 | wake.txt concurrent 30 wake_all |
Pliki są w sandboxd/bench/results/2026-10-03-s3-ryzen9950x/4c8g-layers-final/; opis to sandboxd/bench/results/README.md, runda 2, sekcja 二. Pozostałe strony serwisu odczytują liczby dla uśpienia i wybudzenia (3.5 ms na wybudzenie, 2.3 ms na uśpienie) z tego samego pliku co ta tabela, więc pochodzą z tej rundy. Migawkę sprawdziliśmy strona po stronie z całą pamięcią, którą Firecracker sam zapisał: różniły się 3 bajty jednej strony spośród 2 097 152.
Tę samą liczbę możesz odczytać dla własnych piaskownic: każde wywołanie API, które musiało którąś wybudzić, podaje czas wybudzenia w milisekundach w nagłówku Server-Timing: wake;dur=….
CPU: otwarty benchmark StarSling
StarSling publikuje otwarty benchmark dostawców piaskownic (github.com/starslingdev/hpc-sandbox-benchmarks). Jego wynik CPU mierzy narzędzia webowe Node.js w piaskownicy z 4 vCPU i 8 GiB, w przebiegach na sekundę. Uruchomiliśmy ten zestaw testów w piaskownicy Glac i porównaliśmy wynik z dostawcami z ostatniego opublikowanego uruchomienia, które obejmuje nasza kopia jego danych.
- Glac, przebiegi na sekundę
- 29.0
- mediana 13 dostawców
- 17.26
- szybciej niż ta mediana
- 68%
Nasz wynik
- Nasz pierwszy serwer produkcyjny w Coventry (Wielka Brytania): AMD Ryzen 9 9950X ze 128 GB, 10 października 2026, podczas testów odbiorczych, gdy żadna inna piaskownica go nie obciążała.
- Własny zestaw testów i obraz StarSling (
sandbox-benchmarks-toolchain:v8), w piaskownicy z 4 vCPU i 8 GiB, uruchomione tak, jak uruchamia je produkt. - Trzy przejścia zestawu testów; każde przejście to mediana z jego trzech prób: 28.97, 29.27, 29.00. Wynik to ich mediana, 29.00.
Ich wyniki
- Uruchomienie StarSling nr 36498291449: to, które ich ranking pokazywał 2 października 2026, gdy robiliśmy kopię jego danych, i najnowsze z dziewięciu uruchomień w tej kopii (23–29 września 2026).
- Wartość dostawcy to mediana, liczona po wszystkich jego piaskownicach, z mediany prób każdej z nich: tak liczy sam ranking.
- Nasza kopia przechowuje każdą wartość jako stosunek do wartości jednego dostawcy z tego samego uruchomienia, z dokładnością do trzech miejsc po przecinku, więc każda wartość poniżej różni się od wartości StarSling najwyżej o około 0.02.
Nasz wynik i 13 wartości, przebiegi na sekundę, od najwyższej
29.0 ÷ 17.26 = 1.68, czyli o 68% szybciej niż mediana. Nazwy dostawców są w danych opublikowanych przez StarSling; wartości tutaj są odczytywane podczas budowania strony z reports/providers/sources/performance-bar/starsling-metrics.tsv, utworzonego z tych danych przez leżący obok analyse.py.
Czego ten wynik nie mówi
- Nasz pomiar odbył się, gdy nic innego nie obciążało maszyny; ich pomiary – przy tym, co tego dnia działało na ich hostach. Obciążona maszyna obniża wynik: na 9950X z 1.25 innego zajętego vCPU na każdy rdzeń ten sam zestaw osiągnął w naszej piaskownicy 10.4 (8 października 2026). Ci sąsiedzi uruchamiali w pętli ten sam test, obciążenie najbardziej zachłanne na cache, jakie istnieje, cięższe niż prawdziwa flota.
- To jeden benchmark jednego rodzaju pracy: Node.js uruchamia narzędzia JavaScript, co zależy od szybkości rdzeni. Nie mówi nic o dyskach ani sieciach.
Pliki
sandboxd/bench/results/2026-10-10-cvt-01-accept/: odbiór serwera, jego surowe wyjście iresults.jsonreports/providers/sources/performance-bar/starsling-metrics.tsvreports/providers/sources/performance-bar.md: jak powstała i jak jest odczytywana kopiasandboxd/bench/results/README.md: sekcje 40 i 42
Gdzie są surowe wyniki
Każda ścieżka na tej stronie to plik we własnym repozytorium Glac, obok kodu, który wykonał pomiar. Repozytorium nie jest publiczne; ścieżki mówią, z którego przebiegu pochodzi każda liczba, a opis każdej rundy mówi, co uruchomiono, na czym i co poszło nie tak.