Come misuriamo
I numeri che questo sito presenta come misurati sono stati misurati su bare metal, sul processore dei nostri server di produzione: sonno, risveglio e snapshot, e il benchmark della CPU. Eccoli uno per uno, con la macchina, il giorno, come sono stati rilevati e dove si trovano i risultati grezzi.
- Bare metal. Un’intera macchina fisica, non una macchina virtuale su quella di qualcun altro: niente che non possiamo vedere la condivide.
- Mediane, con la loro dispersione. Il valore centrale di molte esecuzioni, con accanto il 95° percentile e il numero di esecuzioni.
- Il caso più favorevole è dichiarato come tale. Quasi tutte queste misure sono state prese senza altro lavoro sulla macchina; dove è così, la pagina lo dice.
- Risultati grezzi conservati. Ogni cifra indica il file da cui è stata letta, nel repository insieme al codice che l’ha prodotta.
Sonno, risveglio e snapshot
- Macchina
- Cherry Servers, Singapore: AMD Ryzen 9 9950X (Zen 5, 16 core), 128 GB, Ubuntu 26.04.1, kernel 7.0.0-34
- Data
- 3 ottobre 2026
- Sandbox
- Sandbox da 4 vCPU / 8 GiB, node:24-bookworm
- Nodo
- sandboxd con le impostazioni predefinite di quel giorno: un Firecracker con patch, la memoria su due livelli, un processo tenuto pronto per ogni sandbox dormiente, i dispositivi su PCI
- Chiamante
- sulla stessa macchina, su un’unica connessione tenuta aperta, così una cifra misura la richiesta stessa e non un handshake
| Cosa | Come si misura il tempo | Mediana | p95 | Esecuzioni | Fonte |
|---|---|---|---|---|---|
| Messa in sonno | POST …/sleep, come l’ha visto il chiamante | 2.3 ms | 2.8 ms | 30 | wake.txt cycle sleep |
| Risveglio, dopo che si è addormentata da sola | il tempo di ripristino contato dal nodo stesso (la sua intestazione Server-Timing), per la chiamata successiva | 3.5 ms | 3.9 ms | 29 | wake.txt auto wake |
| Quella chiamata, fino alla risposta | l’intera richiesta che l’ha svegliata, dall’invio alla risposta | 6.7 ms | 7.1 ms | 29 | wake.txt auto call |
| Risveglio, subito dopo essersi addormentata | il processo tenuto pronto per il prossimo risveglio si sta ancora avviando, quindi attende | 5.6 ms | 6.3 ms | 30 | wake.txt cycle wake |
| Snapshot di una sandbox in esecuzione | tramite l’API: memoria, processi e disco, mentre è in esecuzione | 32 ms | — | 4 | snapshot.txt 31.5 to 31.9 ms |
| Creata, dal pool | una copia di un template già in esecuzione | 1.3 ms | — | 100 | tti-sequential.txt create median |
| Creata, fino alla risposta al primo comando | una dopo l’altra, cento volte | 11.0 ms | 12.0 ms | 100 | tti-sequential.txt sequential x100 |
| 30 insieme: tutte addormentate | trenta sandbox addormentate nello stesso istante, fino all’ultima | 49.0 ms | — | 1 | wake.txt concurrent 30 sleep_all |
| 30 insieme: tutte sveglie | le stesse trenta svegliate nello stesso istante, fino all’ultima | 61.4 ms | — | 1 | wake.txt concurrent 30 wake_all |
I file sono in sandboxd/bench/results/2026-10-03-s3-ryzen9950x/4c8g-layers-final/; il resoconto è sandboxd/bench/results/README.md, round 2, sezione 二. Le altre pagine del sito leggono le cifre di sonno e risveglio (3.5 ms per svegliarsi, 2.3 ms per addormentarsi) dallo stesso file di questa tabella, quindi sono di questo round. Lo snapshot è stato verificato pagina per pagina con l’intera memoria scritta da Firecracker stesso: differivano 3 byte di una pagina su 2 097 152.
Puoi leggere la stessa cifra per le tue sandbox: ogni chiamata API che ha dovuto svegliarne una dice quanto ci è voluto, in millisecondi, nella sua intestazione Server-Timing: wake;dur=….
CPU: il benchmark aperto di StarSling
StarSling pubblica un benchmark aperto dei provider di sandbox (github.com/starslingdev/hpc-sandbox-benchmarks). Il suo punteggio CPU è il web tooling di Node.js in una sandbox da 4 vCPU e 8 GiB, in esecuzioni al secondo. Abbiamo eseguito la sua suite in una sandbox Glac e confrontato il risultato con i provider della sua ultima esecuzione pubblicata presente nella nostra copia dei suoi dati.
- Glac, esecuzioni al secondo
- 29.0
- la mediana di 13 provider
- 17.26
- più veloce di quella mediana
- 68%
Il nostro
- Il nostro primo server di produzione, a Coventry, Regno Unito: un AMD Ryzen 9 9950X con 128 GB, il 10 ottobre 2026, durante il collaudo, senza nessun’altra sandbox al lavoro.
- La suite e l’immagine di StarSling (
sandbox-benchmarks-toolchain:v8), in una sandbox da 4 vCPU e 8 GiB, eseguita come la esegue il prodotto. - Tre passate della suite; ogni passata è la mediana delle sue tre prove: 28.97, 29.27, 29.00. La cifra è la loro mediana, 29.00.
Il loro
- L’esecuzione 36498291449 di StarSling: quella che la sua classifica mostrava il 2 ottobre 2026, quando abbiamo preso la nostra copia dei suoi dati, e l’ultima delle nove esecuzioni di quella copia (23–29 settembre 2026).
- Il valore di un provider è la mediana, sulle sue sandbox, della prova mediana di ciascuna sandbox: la regola della classifica stessa.
- La nostra copia conserva ogni valore come rapporto con quello di un provider della stessa esecuzione, a tre decimali, quindi ogni valore qui sotto si discosta al massimo di circa 0.02 da quello di StarSling.
Il nostro e i valori dei provider, 13 in tutto, in esecuzioni al secondo, dal più alto
29.0 ÷ 17.26 = 1.68, quindi 68% più veloce della mediana. I nomi dei provider sono nei dati pubblicati da StarSling; i valori qui sono letti durante la build da reports/providers/sources/performance-bar/starsling-metrics.tsv, ricavato da quei dati con analyse.py, che gli sta accanto.
Cosa non dice
- Il nostro è stato eseguito senza nient’altro al lavoro sulla macchina; i loro su qualunque carico avessero i loro host quel giorno. Una macchina sotto carico abbassa il punteggio: su un 9950X con 1.25 altre vCPU al lavoro per ciascuno dei suoi core, la stessa suite ha totalizzato 10.4 nella nostra sandbox (8 ottobre 2026). Quei vicini eseguivano lo stesso test in ciclo, il carico più affamato di cache che esista, più pesante di una flotta reale.
- È un solo benchmark di un solo tipo di lavoro (Node.js che esegue strumenti JavaScript), che dipende dalla velocità dei core. Non dice nulla di dischi o reti.
I file
sandboxd/bench/results/2026-10-10-cvt-01-accept/: il collaudo, il suo output grezzo eresults.jsonreports/providers/sources/performance-bar/starsling-metrics.tsvreports/providers/sources/performance-bar.md: come è stata fatta e letta la copiasandboxd/bench/results/README.md: sezioni 40 e 42
Dove sono i risultati grezzi
Ogni percorso in questa pagina è un file del repository di Glac, accanto al codice che ha preso la misura. Il repository non è pubblico; i percorsi dicono da quale esecuzione viene ogni cifra, e il resoconto di ogni round dice cosa è stato eseguito, su cosa e cosa è andato storto.