Comment nous mesurons
Les chiffres que ce site donne comme mesurés l’ont été sur bare metal, sur le processeur qu’utilisent nos serveurs de production : sommeil, réveil et instantané, et le benchmark CPU. Les voici un par un, avec la machine, le jour, la façon dont chacun a été mesuré et l’endroit où sont ses résultats bruts.
- Bare metal. Une machine physique entière, et non une machine virtuelle sur celle d’un autre : rien que nous ne puissions voir ne la partage.
- Des médianes, avec leur dispersion. La valeur centrale de nombreuses exécutions, avec à côté le 95e centile et le nombre d’exécutions.
- Le meilleur des cas est présenté comme tel. La plupart ont tourné sans rien d’autre d’actif sur la machine ; quand c’est le cas, la page le dit.
- Résultats bruts conservés. Chaque chiffre nomme le fichier d’où il est tiré, dans le dépôt, à côté du code qui l’a produit.
Sommeil, réveil et instantané
- Machine
- Cherry Servers, Singapour : AMD Ryzen 9 9950X (Zen 5, 16 cœurs), 128 GB, Ubuntu 26.04.1, noyau 7.0.0-34
- Jour
- 3 octobre 2026
- Bac à sable
- Bac à sable de 4 vCPU / 8 GiB, node:24-bookworm
- Nœud
- sandboxd avec les réglages par défaut du jour : un Firecracker patché, la mémoire en deux couches, un processus gardé prêt pour chaque bac à sable endormi, les périphériques sur PCI
- Appelant
- sur la même machine, par une seule connexion gardée ouverte : un chiffre mesure la requête elle-même, et non une négociation de connexion
| Mesure | Méthode de chronométrage | Médiane | p95 | Exécutions | Lu dans |
|---|---|---|---|---|---|
| Mise en sommeil | POST …/sleep, vu par l’appelant | 2.3 ms | 2.8 ms | 30 | wake.txt cycle sleep |
| Réveil, après s’être endormi de lui-même | le temps de restauration compté par le nœud lui-même (son en-tête Server-Timing), pour l’appel suivant | 3.5 ms | 3.9 ms | 29 | wake.txt auto wake |
| Cet appel, jusqu’à la réponse | toute la requête qui l’a réveillé, de l’envoi à la réponse | 6.7 ms | 7.1 ms | 29 | wake.txt auto call |
| Réveil, juste après une mise en sommeil | le processus gardé prêt pour le prochain réveil est encore en train de démarrer : il attend donc | 5.6 ms | 6.3 ms | 30 | wake.txt cycle wake |
| Instantané d’un bac à sable en marche | par l’API : mémoire, processus et disque, pendant qu’il tourne | 32 ms | — | 4 | snapshot.txt 31.5 to 31.9 ms |
| Création, depuis le pool | une copie d’un modèle déjà en marche | 1.3 ms | — | 100 | tti-sequential.txt create median |
| Création, jusqu’à la réponse à sa première commande | l’un après l’autre, cent fois | 11.0 ms | 12.0 ms | 100 | tti-sequential.txt sequential x100 |
| 30 à la fois : tous endormis | trente bacs à sable endormis au même moment, jusqu’au dernier | 49.0 ms | — | 1 | wake.txt concurrent 30 sleep_all |
| 30 à la fois : tous réveillés | les trente mêmes, réveillés au même moment, jusqu’au dernier | 61.4 ms | — | 1 | wake.txt concurrent 30 wake_all |
Les fichiers sont dans sandboxd/bench/results/2026-10-03-s3-ryzen9950x/4c8g-layers-final/ ; le compte rendu est sandboxd/bench/results/README.md, série 2, section 二. Les autres pages du site lisent leurs chiffres de sommeil et de réveil (3.5 ms pour se réveiller, 2.3 ms pour s’endormir) dans le même fichier que ce tableau : ce sont donc ceux de cette série. L’instantané a été comparé page par page à la mémoire entière que Firecracker a lui-même écrite : 3 octets d’une page sur 2 097 152 différaient.
Vous pouvez lire le même chiffre pour vos propres bacs à sable : chaque appel d’API qui a dû en réveiller un indique combien de temps cela a pris, en millisecondes, dans son en-tête Server-Timing: wake;dur=….
CPU : le benchmark ouvert de StarSling
StarSling publie un benchmark ouvert des fournisseurs de bacs à sable (github.com/starslingdev/hpc-sandbox-benchmarks). Son score CPU porte sur l’outillage web de Node.js dans un bac à sable de 4 vCPU et 8 GiB, en exécutions par seconde. Nous avons lancé sa suite dans un bac à sable Glac et comparé le résultat aux fournisseurs de la dernière exécution publiée que contient notre copie de ses données.
- Glac, exécutions par seconde
- 29.0
- la médiane de 13 fournisseurs
- 17.26
- plus rapide que cette médiane
- 68%
Le nôtre
- Notre premier serveur de production, à Coventry (Royaume-Uni) : un AMD Ryzen 9 9950X avec 128 GB, le 10 octobre 2026, pendant son test de recette, sans autre bac à sable actif dessus.
- La suite et l’image de StarSling elles-mêmes (
sandbox-benchmarks-toolchain:v8), dans un bac à sable de 4 vCPU et 8 GiB, lancées comme le produit les lance. - Trois passes de la suite ; chaque passe est la médiane de ses trois essais : 28.97, 29.27, 29.00. Le chiffre retenu est leur médiane, 29.00.
Les leurs
- L’exécution 36498291449 de StarSling : celle qu’affichait son classement le 2 octobre 2026, quand nous avons pris notre copie de ses données, et la plus récente des neuf exécutions de cette copie (du 23 au 29 septembre 2026).
- La valeur d’un fournisseur est la médiane, sur ses bacs à sable, de l’essai médian de chacun : la règle du classement lui-même.
- Notre copie garde chaque valeur sous forme de rapport à celle d’un fournisseur de la même exécution, à trois décimales : chaque valeur ci-dessous est donc à environ 0.02 près de celle de StarSling.
Le nôtre et les 13 valeurs, en exécutions par seconde, de la plus haute à la plus basse
29.0 ÷ 17.26 = 1.68, soit 68 % plus rapide que la médiane. Les noms des fournisseurs figurent dans les données publiées par StarSling ; les valeurs affichées ici sont lues à la génération du site dans reports/providers/sources/performance-bar/starsling-metrics.tsv, produit à partir de ces données par analyse.py, juste à côté.
Ce qu’il ne dit pas
- Le nôtre a tourné sans rien d’autre d’actif sur la machine ; les leurs, avec la charge que leurs hôtes supportaient ce jour-là. Une machine chargée fait baisser le score : sur un 9950X avec, pour chacun de ses cœurs, 1.25 autre vCPU actif, la même suite a obtenu 10.4 dans notre bac à sable (8 octobre 2026). Ces voisins faisaient tourner le même test en boucle, la charge la plus gourmande en cache qui soit, plus lourde qu’une vraie flotte.
- C’est un benchmark d’un seul type de travail, Node.js exécutant des outils JavaScript, qui suit la vitesse des cœurs. Il ne dit rien des disques ni des réseaux.
Les fichiers
sandboxd/bench/results/2026-10-10-cvt-01-accept/: la recette, sa sortie brute etresults.jsonreports/providers/sources/performance-bar/starsling-metrics.tsvreports/providers/sources/performance-bar.md: comment la copie a été faite et luesandboxd/bench/results/README.md: sections 40 et 42
Où sont les résultats bruts
Chaque chemin de cette page est un fichier du dépôt de Glac, à côté du code qui a pris la mesure. Le dépôt n’est pas public ; les chemins disent de quelle exécution vient chaque chiffre, et le compte rendu de chaque série dit ce qui a tourné, sur quoi, et ce qui s’est mal passé.