Hoe we meten
De getallen die deze site als gemeten opgeeft, zijn gemeten op bare metal, op de processor die onze productieservers gebruiken: slapen, wakker worden en snapshot, en de CPU-benchmark. Hier staat elk getal, met de machine, de dag, hoe het gemeten is en waar de ruwe resultaten staan.
- Bare metal. Een hele fysieke machine, geen virtuele machine op die van een ander, dus er draait niets op mee wat wij niet kunnen zien.
- Medianen, met hun spreiding. De middelste waarde van veel runs, met het 95e percentiel en het aantal runs ernaast.
- Het gunstigste geval noemen we ook zo. De meeste draaiden terwijl er verder niets actief was op de machine; waar dat zo is, staat het op de pagina.
- Ruwe resultaten bewaard. Bij elk getal staat het bestand waaruit het gelezen is, in de repository met de code die het maakte.
Slapen, wakker worden en snapshot
- Machine
- Cherry Servers, Singapore: AMD Ryzen 9 9950X (Zen 5, 16 cores), 128 GB, Ubuntu 26.04.1, kernel 7.0.0-34
- Dag
- 3 oktober 2026
- Sandbox
- sandbox met 4 vCPU / 8 GiB, node:24-bookworm
- Node
- sandboxd met de standaardinstellingen van die dag: een gepatchte Firecracker, geheugen in twee lagen, een proces dat klaarstaat voor elke slapende sandbox, apparaten op PCI
- Aanroeper
- op dezelfde machine, via één verbinding die open blijft, dus een getal is het verzoek zelf en geen handshake
| Wat | Hoe het gemeten wordt | Mediaan | p95 | Runs | Gelezen uit |
|---|---|---|---|---|---|
| In slaap brengen | POST …/sleep, zoals de aanroeper het zag | 2.3 ms | 2.8 ms | 30 | wake.txt cycle sleep |
| Wekken, nadat hij vanzelf in slaap viel | de tijd die de node zelf telt voor het herstellen (zijn Server-Timing-header), bij de volgende aanroep | 3.5 ms | 3.9 ms | 29 | wake.txt auto wake |
| Die aanroep, beantwoord | het hele verzoek dat hem wekte, van verzonden tot beantwoord | 6.7 ms | 7.1 ms | 29 | wake.txt auto call |
| Wekken, meteen nadat hij ging slapen | het proces dat voor het volgende wekken klaarstaat, is nog aan het opstarten, dus het wekken wacht | 5.6 ms | 6.3 ms | 30 | wake.txt cycle wake |
| Snapshot van een draaiende sandbox | via de API: geheugen, processen en schijf, terwijl hij draait | 32 ms | — | 4 | snapshot.txt 31.5 to 31.9 ms |
| Aangemaakt, uit de pool | een kopie van een template die al draait | 1.3 ms | — | 100 | tti-sequential.txt create median |
| Aangemaakt, tot het antwoord op het eerste commando | achter elkaar, honderd keer | 11.0 ms | 12.0 ms | 100 | tti-sequential.txt sequential x100 |
| 30 tegelijk: allemaal in slaap | dertig sandboxen op hetzelfde moment in slaap gebracht, tot de laatste | 49.0 ms | — | 1 | wake.txt concurrent 30 sleep_all |
| 30 tegelijk: allemaal wakker | dezelfde dertig op hetzelfde moment gewekt, tot de laatste | 61.4 ms | — | 1 | wake.txt concurrent 30 wake_all |
De bestanden staan in sandboxd/bench/results/2026-10-03-s3-ryzen9950x/4c8g-layers-final/; het verslag is sandboxd/bench/results/README.md, ronde 2, sectie 二. De andere pagina’s van de site lezen hun getallen voor slapen en wakker worden (3.5 ms om wakker te worden, 2.3 ms om in slaap te vallen) uit hetzelfde bestand als deze tabel, dus ze komen uit deze ronde. De snapshot is pagina voor pagina vergeleken met het hele geheugen dat Firecracker zelf wegschreef: 3 bytes van één pagina op 2 097 152 verschilden.
Je kunt hetzelfde getal voor je eigen sandboxen aflezen: elke API-aanroep die er een moest wekken, zegt in zijn Server-Timing: wake;dur=…-header hoe lang dat duurde, in milliseconden.
CPU: de open benchmark van StarSling
StarSling publiceert een open benchmark van sandboxaanbieders (github.com/starslingdev/hpc-sandbox-benchmarks). De CPU-score is Node.js-webtooling in een sandbox met 4 vCPU’s en 8 GiB, in runs per seconde. We hebben de suite in een Glac-sandbox gedraaid en het resultaat vergeleken met de aanbieders in de laatst gepubliceerde run die onze kopie van de data bevat.
- Glac, runs per seconde
- 29.0
- de mediaan van 13 aanbieders
- 17.26
- sneller dan die mediaan
- 68%
Onze meting
- Onze eerste productieserver, in Coventry (VK): een AMD Ryzen 9 9950X met 128 GB, op 10 oktober 2026, tijdens de acceptatietest, zonder andere actieve sandbox erop.
- De eigen suite en het eigen image van StarSling (
sandbox-benchmarks-toolchain:v8), in een sandbox met 4 vCPU’s en 8 GiB, gedraaid zoals het product het draait. - Drie rondes van de suite; elke ronde is de mediaan van drie pogingen: 28.97, 29.27, 29.00. Het getal is hun mediaan, 29.00.
Hun metingen
- Run 36498291449 van StarSling: de run die de ranglijst toonde op 2 oktober 2026, toen we onze kopie van de data maakten, en de laatste van de negen runs in die kopie (23 tot en met 29 september 2026).
- De waarde van een aanbieder is de mediaan, over zijn sandboxen, van de mediane poging van elke sandbox: de eigen regel van de ranglijst.
- Onze kopie bewaart elke waarde als verhouding tot die van één aanbieder in dezelfde run, op drie decimalen, dus elke waarde hieronder ligt binnen ongeveer 0.02 van die van StarSling zelf.
Onze waarde en de 13 waarden, in runs per seconde, hoogste eerst
29.0 ÷ 17.26 = 1.68, dus 68% sneller dan de mediaan. De namen van de aanbieders staan in de gepubliceerde data van StarSling; de waarden hier worden bij het bouwen gelezen uit reports/providers/sources/performance-bar/starsling-metrics.tsv, dat analyse.py ernaast uit die data maakt.
Wat het niet zegt
- Onze meting draaide terwijl er verder niets actief was op de machine; die van hen draaiden naast alles wat hun hosts die dag te verwerken hadden. Een drukke machine verlaagt de score: op een 9950X met 1.25 andere actieve vCPU’s per core scoorde dezelfde suite 10.4 in onze sandbox (8 oktober 2026). Die buren draaiden dezelfde test in een lus, de meest cachehongerige belasting die er is, zwaarder dan een echt serverpark.
- Het is één benchmark van één soort werk, Node.js dat JavaScript-tools draait, en dat volgt de snelheid van de cores. Over schijven of netwerken zegt het niets.
De bestanden
sandboxd/bench/results/2026-10-10-cvt-01-accept/: de acceptatietest, de ruwe uitvoer enresults.jsonreports/providers/sources/performance-bar/starsling-metrics.tsvreports/providers/sources/performance-bar.md: hoe de kopie gemaakt en gelezen issandboxd/bench/results/README.md: secties 40 en 42
Waar de ruwe resultaten staan
Elk pad op deze pagina is een bestand in de eigen repository van Glac, naast de code die de meting deed. De repository is niet openbaar; de paden zeggen uit welke run elk getal komt, en het verslag van elke ronde zegt wat er gedraaid is, waarop, en wat er misging.