Wie wir messen
Die Zahlen, die diese Website als gemessen angibt, wurden auf Bare Metal gemessen, auf dem Prozessor unserer Produktionsserver: Schlafen, Aufwachen und Snapshot sowie der CPU-Benchmark. Hier steht jede einzelne, mit Maschine, Tag, Messverfahren und dem Ort ihrer Rohdaten.
- Bare Metal. Eine ganze physische Maschine, keine virtuelle auf der Hardware eines anderen; nichts, was wir nicht sehen, teilt sie mit uns.
- Mediane, mit ihrer Streuung. Der mittlere Wert vieler Durchläufe, daneben das 95. Perzentil und die Zahl der Durchläufe.
- Ein Idealfall heißt auch so. Die meisten liefen, während sonst nichts auf der Maschine arbeitete; wo das so ist, sagt es die Seite.
- Rohdaten aufbewahrt. Jeder Wert nennt die Datei, aus der er gelesen wurde, im Repository mit dem Code, der ihn erzeugt hat.
Schlafen, Aufwachen und Snapshot
- Maschine
- Cherry Servers, Singapur: AMD Ryzen 9 9950X (Zen 5, 16 Kerne), 128 GB, Ubuntu 26.04.1, Kernel 7.0.0-34
- Tag
- 3. Oktober 2026
- Sandbox
- Sandbox mit 4 vCPU / 8 GiB, node:24-bookworm
- Knoten
- sandboxd mit den Standardeinstellungen jenes Tages: ein gepatchter Firecracker, Arbeitsspeicher in zwei Schichten, ein bereitgehaltener Prozess für jede schlafende Sandbox, Geräte an PCI
- Aufrufer
- auf derselben Maschine, über eine offen gehaltene Verbindung, damit ein Wert die Anfrage selbst misst und keinen Handshake
| Messung | Messverfahren | Median | p95 | Durchläufe | Quelle |
|---|---|---|---|---|---|
| Schlafen legen | POST …/sleep, aus Sicht des Aufrufers | 2.3 ms | 2.8 ms | 30 | wake.txt cycle sleep |
| Aufwachen, nachdem sie von selbst eingeschlafen ist | wie der Knoten selbst das Wiederherstellen misst (sein Server-Timing-Header), für den nächsten Aufruf | 3.5 ms | 3.9 ms | 29 | wake.txt auto wake |
| Dieser Aufruf, beantwortet | die ganze Anfrage, die sie geweckt hat, vom Senden bis zur Antwort | 6.7 ms | 7.1 ms | 29 | wake.txt auto call |
| Aufwachen, gleich nach dem Einschlafen | der für das nächste Aufwachen bereitgehaltene Prozess startet noch, also wartet sie | 5.6 ms | 6.3 ms | 30 | wake.txt cycle wake |
| Snapshot einer laufenden Sandbox | über die API: Arbeitsspeicher, Prozesse und Festplatte, während sie läuft | 32 ms | — | 4 | snapshot.txt 31.5 to 31.9 ms |
| Erstellt, aus dem Pool | eine Kopie einer bereits laufenden Vorlage | 1.3 ms | — | 100 | tti-sequential.txt create median |
| Erstellt, bis zur Antwort auf den ersten Befehl | nacheinander, hundertmal | 11.0 ms | 12.0 ms | 100 | tti-sequential.txt sequential x100 |
| 30 gleichzeitig: bis alle schlafen | dreißig Sandboxen, im selben Moment schlafen gelegt, bis zur letzten | 49.0 ms | — | 1 | wake.txt concurrent 30 sleep_all |
| 30 gleichzeitig: bis alle wach sind | dieselben dreißig, im selben Moment geweckt, bis zur letzten | 61.4 ms | — | 1 | wake.txt concurrent 30 wake_all |
Die Dateien liegen in sandboxd/bench/results/2026-10-03-s3-ryzen9950x/4c8g-layers-final/; der Bericht ist sandboxd/bench/results/README.md, Runde 2, Abschnitt 二. Die anderen Seiten der Website lesen ihre Werte zum Schlafen und Aufwachen (3.5 ms zum Aufwachen, 2.3 ms zum Einschlafen) aus derselben Datei wie diese Tabelle, sie stammen also aus dieser Runde. Der Snapshot wurde Seite für Seite mit dem gesamten Arbeitsspeicher verglichen, den Firecracker selbst geschrieben hat: 3 Bytes einer einzigen von 2 097 152 Seiten wichen ab.
Denselben Wert kannst du für deine eigenen Sandboxen ablesen: Jeder API-Aufruf, der eine wecken musste, nennt in seinem Header Server-Timing: wake;dur=… die Dauer in Millisekunden.
CPU: der offene Benchmark von StarSling
StarSling veröffentlicht einen offenen Benchmark von Sandbox-Anbietern (github.com/starslingdev/hpc-sandbox-benchmarks). Sein CPU-Wert ist Node.js-Web-Tooling in einer Sandbox mit 4 vCPUs und 8 GiB, in Durchläufen pro Sekunde. Wir haben seine Suite in einer Glac-Sandbox ausgeführt und das Ergebnis mit den Anbietern seines neuesten veröffentlichten Laufs verglichen, die unsere Kopie seiner Daten enthält.
- Glac, Durchläufe pro Sekunde
- 29.0
- der Median von 13 Anbietern
- 17.26
- schneller als dieser Median
- 68%
Unser Lauf
- Unser erster Produktionsserver, in Coventry, Großbritannien: ein AMD Ryzen 9 9950X mit 128 GB, am 10. Oktober 2026, während seines Abnahmetests, ohne dass eine andere Sandbox darauf aktiv war.
- Die eigene Suite und das eigene Image von StarSling (
sandbox-benchmarks-toolchain:v8), in einer Sandbox mit 4 vCPUs und 8 GiB, so ausgeführt, wie das Produkt sie ausführt. - Drei Durchgänge der Suite; jeder Durchgang ist der Median seiner drei Versuche: 28.97, 29.27, 29.00. Der Wert ist ihr Median, 29.00.
Der Lauf von StarSling
- Lauf 36498291449 von StarSling: der Lauf, den seine Rangliste am 2. Oktober 2026 zeigte, als wir unsere Kopie seiner Daten erstellten, und der neueste der neun Läufe in dieser Kopie (23. bis 29. September 2026).
- Der Wert eines Anbieters ist der Median über seine Sandboxen, gebildet aus dem Median-Versuch jeder Sandbox: die eigene Regel der Rangliste.
- Unsere Kopie speichert jeden Wert als Verhältnis zum Wert eines Anbieters im selben Lauf, auf drei Nachkommastellen, daher weicht jeder Wert unten um höchstens etwa 0.02 von dem von StarSling ab.
Unser Wert und die 13 Werte, Durchläufe pro Sekunde, der höchste zuerst
29.0 ÷ 17.26 = 1.68, also 68% schneller als der Median. Die Namen der Anbieter stehen in den veröffentlichten Daten von StarSling; die Werte hier werden beim Build aus reports/providers/sources/performance-bar/starsling-metrics.tsv gelesen, das analyse.py daneben aus diesen Daten erzeugt.
Was er nicht aussagt
- Unser Lauf lief ohne andere Last auf der Maschine; ihre liefen neben allem, was ihre Hosts an dem Tag sonst zu tragen hatten. Eine ausgelastete Maschine senkt den Wert: Auf einem 9950X mit 1.25 anderen aktiven vCPUs pro Kern erreichte dieselbe Suite in unserer Sandbox 10.4 (8. Oktober 2026). Diese Nachbarn ließen denselben Test in einer Schleife laufen, die cache-hungrigste Last, die es gibt, schwerer als eine echte Flotte.
- Er ist ein Benchmark einer einzigen Art von Arbeit: Node.js führt JavaScript-Werkzeuge aus, was von der Geschwindigkeit der Kerne abhängt. Über Festplatten oder Netzwerke sagt er nichts.
Die Dateien
sandboxd/bench/results/2026-10-10-cvt-01-accept/: die Abnahme, ihre Rohausgabe undresults.jsonreports/providers/sources/performance-bar/starsling-metrics.tsvreports/providers/sources/performance-bar.md: wie die Kopie erstellt und gelesen wurdesandboxd/bench/results/README.md: Abschnitte 40 und 42
Wo die Rohdaten liegen
Jeder Pfad auf dieser Seite ist eine Datei im eigenen Repository von Glac, neben dem Code, der die Messung durchgeführt hat. Das Repository ist nicht öffentlich; die Pfade zeigen, aus welchem Lauf jeder Wert stammt, und der Bericht jeder Runde sagt, was lief, worauf und was schiefging.