Cómo medimos
Las cifras que este sitio presenta como medidas se midieron en bare metal, con el procesador que usan nuestros servidores de producción: el reposo, el despertar y la instantánea, y el benchmark de CPU. Aquí está cada una, con la máquina, el día, cómo se tomó y dónde están sus resultados en bruto.
- Bare metal. Una máquina física entera, no una máquina virtual sobre la de otro, así que nada que no podamos ver la comparte.
- Medianas, con su dispersión. El valor central de muchas ejecuciones, con el percentil 95 y el número de ejecuciones al lado.
- El mejor caso, señalado como tal. La mayoría se ejecutaron sin nada más en uso en la máquina; donde es así, la página lo dice.
- Resultados en bruto guardados. Cada cifra indica el archivo del que se leyó, en el repositorio junto al código que la obtuvo.
Reposo, despertar e instantánea
- Máquina
- Cherry Servers, Singapur: AMD Ryzen 9 9950X (Zen 5, 16 núcleos), 128 GB, Ubuntu 26.04.1, kernel 7.0.0-34
- Día
- 3 de octubre de 2026
- Sandbox
- sandbox de 4 vCPU / 8 GiB, node:24-bookworm
- Nodo
- sandboxd con los valores predeterminados de ese día: un Firecracker parcheado, memoria en dos capas, un proceso listo para cada sandbox dormido, dispositivos en PCI
- Cliente
- en la misma máquina, por una sola conexión que se mantiene abierta, así que una cifra es la solicitud en sí y no el establecimiento de la conexión
| Qué se mide | Cómo se cronometra | Mediana | p95 | Ejecuciones | Fuente |
|---|---|---|---|---|---|
| Dormir | POST …/sleep, visto desde el cliente | 2.3 ms | 2.8 ms | 30 | wake.txt cycle sleep |
| Despertar, tras dormirse solo | el tiempo de restauración según el propio nodo (su cabecera Server-Timing), para la siguiente llamada | 3.5 ms | 3.9 ms | 29 | wake.txt auto wake |
| Esa llamada, respondida | la solicitud completa que lo despertó, desde que se envía hasta que se responde | 6.7 ms | 7.1 ms | 29 | wake.txt auto call |
| Despertar, justo después de dormirse | el proceso que se mantiene listo para el siguiente despertar aún está arrancando, así que espera | 5.6 ms | 6.3 ms | 30 | wake.txt cycle wake |
| Instantánea de un sandbox en ejecución | a través de la API: memoria, procesos y disco, mientras se ejecuta | 32 ms | — | 4 | snapshot.txt 31.5 to 31.9 ms |
| Creado, desde la reserva | una copia de una plantilla que ya se está ejecutando | 1.3 ms | — | 100 | tti-sequential.txt create median |
| Creado, hasta la respuesta a su primer comando | uno tras otro, cien veces | 11.0 ms | 12.0 ms | 100 | tti-sequential.txt sequential x100 |
| 30 a la vez: todos dormidos | treinta sandboxes puestos a dormir en el mismo instante, hasta que se duerme el último | 49.0 ms | — | 1 | wake.txt concurrent 30 sleep_all |
| 30 a la vez: todos despiertos | los mismos treinta despertados en el mismo instante, hasta que despierta el último | 61.4 ms | — | 1 | wake.txt concurrent 30 wake_all |
Los archivos están en sandboxd/bench/results/2026-10-03-s3-ryzen9950x/4c8g-layers-final/; el informe es sandboxd/bench/results/README.md, ronda 2, sección 二. Las demás páginas del sitio leen sus cifras de reposo y despertar (3.5 ms en despertar, 2.3 ms en dormirse) del mismo archivo que esta tabla, así que son de esta ronda. La instantánea se comprobó página a página contra la memoria completa que escribió el propio Firecracker: de 2 097 152 páginas, en una difirieron 3 bytes.
Puedes leer la misma cifra para tus propios sandboxes: cada llamada a la API que tuvo que despertar uno indica cuánto tardó, en milisegundos, en su cabecera Server-Timing: wake;dur=….
CPU: el benchmark abierto de StarSling
StarSling publica un benchmark abierto de proveedores de sandboxes (github.com/starslingdev/hpc-sandbox-benchmarks). Su puntuación de CPU mide herramientas web de Node.js en un sandbox de 4 vCPU y 8 GiB, en ejecuciones por segundo. Ejecutamos su suite en un sandbox de Glac y comparamos el resultado con los proveedores de su última ejecución publicada que recoge nuestra copia de sus datos.
- Glac, ejecuciones por segundo
- 29.0
- la mediana de 13 proveedores
- 17.26
- más rápido que esa mediana
- 68%
Nuestro resultado
- Nuestro primer servidor de producción, en Coventry (Reino Unido): un AMD Ryzen 9 9950X con 128 GB, el 10 de octubre de 2026, durante su prueba de aceptación, sin ningún otro sandbox en uso.
- La suite y la imagen del propio StarSling (
sandbox-benchmarks-toolchain:v8), en un sandbox de 4 vCPU y 8 GiB, ejecutadas como las ejecuta el producto. - Tres pasadas de la suite; cada pasada es la mediana de sus tres ensayos: 28.97, 29.27, 29.00. La cifra es su mediana, 29.00.
Los de los demás
- La ejecución 36498291449 de StarSling: la que mostraba su clasificación el 2 de octubre de 2026, cuando tomamos nuestra copia de sus datos, y la última de las nueve ejecuciones de esa copia (del 23 al 29 de septiembre de 2026).
- El valor de un proveedor es la mediana, entre sus sandboxes, del ensayo mediano de cada sandbox: la regla de la propia clasificación.
- Nuestra copia guarda cada valor como una proporción respecto al de un proveedor de la misma ejecución, con tres decimales, así que cada valor de abajo difiere como mucho en unos 0.02 del de StarSling.
El nuestro y los 13 valores, en ejecuciones por segundo, de mayor a menor
29.0 ÷ 17.26 = 1.68, es decir, un 68% más rápido que la mediana. Los nombres de los proveedores están en los datos publicados de StarSling; los valores de aquí se leen al compilar el sitio desde reports/providers/sources/performance-bar/starsling-metrics.tsv, generado a partir de esos datos por analyse.py, que está a su lado.
Lo que no dice
- El nuestro se obtuvo sin nada más en uso en la máquina; los de los demás, con lo que llevaran sus hosts ese día. Una máquina cargada baja la puntuación: en un 9950X con 1.25 vCPU más en uso por cada uno de sus núcleos, la misma suite obtuvo 10.4 en nuestro sandbox (8 de octubre de 2026). Esos vecinos ejecutaban la misma prueba en bucle, la carga que más caché consume, más pesada que una flota real.
- Es un benchmark de un solo tipo de trabajo, Node.js ejecutando herramientas de JavaScript, que sigue la velocidad de los núcleos. No dice nada de discos ni de redes.
Los archivos
sandboxd/bench/results/2026-10-10-cvt-01-accept/: la prueba de aceptación, su salida en bruto yresults.jsonreports/providers/sources/performance-bar/starsling-metrics.tsvreports/providers/sources/performance-bar.md: cómo se hizo y se leyó la copiasandboxd/bench/results/README.md: secciones 40 y 42
Dónde están los resultados en bruto
Cada ruta de esta página es un archivo del propio repositorio de Glac, junto al código que tomó la medición. El repositorio no es público; las rutas indican de qué ejecución viene cada cifra, y el informe de cada ronda dice qué se ejecutó, en qué y qué salió mal.