Como medimos
Os números que este site apresenta como medidos foram medidos em bare metal, no processador que nossos servidores de produção usam: sono, despertar e snapshot, e o benchmark de CPU. Aqui está cada um, com a máquina, o dia, como foi obtido e onde estão os resultados brutos.
- Bare metal. Uma máquina física inteira, e não uma máquina virtual na máquina de outra pessoa; assim, nada que não possamos ver a compartilha.
- Medianas, com a dispersão. O valor do meio de muitas execuções, com o percentil 95 e o número de execuções ao lado.
- O melhor caso é declarado como tal. A maioria rodou sem mais nada ocupado na máquina; quando é o caso, a página diz.
- Resultados brutos guardados. Cada número indica o arquivo de onde foi lido, no repositório, junto com o código que o gerou.
Sono, despertar e snapshot
- Máquina
- Cherry Servers, Singapura: AMD Ryzen 9 9950X (Zen 5, 16 núcleos), 128 GB, Ubuntu 26.04.1, kernel 7.0.0-34
- Dia
- 3 de outubro de 2026
- Sandbox
- Sandbox de 4 vCPU / 8 GiB, node:24-bookworm
- Nó
- sandboxd com os padrões daquele dia: um Firecracker com patches, memória em duas camadas, um processo mantido pronto para cada sandbox adormecido, dispositivos em PCI
- Chamador
- na mesma máquina, por uma única conexão mantida aberta; assim, cada número é a própria requisição, e não um handshake
| O quê | Como é cronometrado | Mediana | p95 | Execuções | Fonte |
|---|---|---|---|---|---|
| Colocar para dormir | POST …/sleep, do ponto de vista de quem chamou | 2.3 ms | 2.8 ms | 30 | wake.txt cycle sleep |
| Acordar, depois de adormecer sozinho | o tempo de restauração contado pelo próprio nó (o cabeçalho Server-Timing), para a próxima chamada | 3.5 ms | 3.9 ms | 29 | wake.txt auto wake |
| Essa chamada, respondida | a requisição inteira que o acordou, do envio à resposta | 6.7 ms | 7.1 ms | 29 | wake.txt auto call |
| Acordar, logo depois de dormir | o processo mantido pronto para acordá-lo da próxima vez ainda está iniciando, então ele espera | 5.6 ms | 6.3 ms | 30 | wake.txt cycle wake |
| Snapshot de um sandbox em execução | pela API: memória, processos e disco, enquanto ele roda | 32 ms | — | 4 | snapshot.txt 31.5 to 31.9 ms |
| Criado, a partir do pool | uma cópia de um template já em execução | 1.3 ms | — | 100 | tti-sequential.txt create median |
| Criado, até a resposta do primeiro comando | um após o outro, cem vezes | 11.0 ms | 12.0 ms | 100 | tti-sequential.txt sequential x100 |
| 30 de uma vez: todos dormindo | trinta sandboxes colocados para dormir no mesmo instante, até o último | 49.0 ms | — | 1 | wake.txt concurrent 30 sleep_all |
| 30 de uma vez: todos acordados | os mesmos trinta acordados no mesmo instante, até o último | 61.4 ms | — | 1 | wake.txt concurrent 30 wake_all |
Os arquivos estão em sandboxd/bench/results/2026-10-03-s3-ryzen9950x/4c8g-layers-final/; o relatório é sandboxd/bench/results/README.md, rodada 2, seção 二. As outras páginas do site leem os tempos para dormir e acordar (3.5 ms para acordar, 2.3 ms para dormir) do mesmo arquivo desta tabela, então eles são desta rodada. O snapshot foi conferido página por página com a memória inteira que o próprio Firecracker gravou: 3 bytes de uma página em 2 097 152 eram diferentes.
Você pode ler o mesmo número para os seus próprios sandboxes: toda chamada de API que precisou acordar um deles diz quanto tempo isso levou, em milissegundos, no cabeçalho Server-Timing: wake;dur=….
CPU: o benchmark aberto da StarSling
A StarSling publica um benchmark aberto de provedores de sandbox (github.com/starslingdev/hpc-sandbox-benchmarks). A pontuação de CPU dele é a de ferramentas web em Node.js em um sandbox de 4 vCPUs e 8 GiB, em execuções por segundo. Rodamos a suíte em um sandbox do Glac e comparamos o resultado com os provedores da rodada publicada mais recente que a nossa cópia dos dados dela contém.
- Glac, execuções por segundo
- 29.0
- a mediana de 13 provedores
- 17.26
- mais rápido que essa mediana
- 68%
Nossa medição
- Nosso primeiro servidor de produção, em Coventry, Reino Unido: um AMD Ryzen 9 9950X com 128 GB, em 10 de outubro de 2026, durante o teste de aceitação, sem nenhum outro sandbox ocupado nele.
- A própria suíte e a imagem da StarSling (
sandbox-benchmarks-toolchain:v8), em um sandbox de 4 vCPUs e 8 GiB, executado como o produto o executa. - Três passadas da suíte; cada passada é a mediana das suas três tentativas: 28.97, 29.27, 29.00. O número final é a mediana delas, 29.00.
A medição deles
- A rodada 36498291449 da StarSling: a rodada que o ranking dela mostrava em 2 de outubro de 2026, quando fizemos nossa cópia dos dados, e a mais recente das nove rodadas dessa cópia (23 a 29 de setembro de 2026).
- O valor de um provedor é a mediana, entre os seus sandboxes, da tentativa mediana de cada sandbox: a regra do próprio ranking.
- Nossa cópia guarda cada valor como uma razão em relação ao de um provedor na mesma rodada, com três casas decimais; por isso, cada valor abaixo fica a cerca de 0.02 do valor da própria StarSling.
A nossa e os 13 valores deles, em execuções por segundo, do maior para o menor
29.0 ÷ 17.26 = 1.68, ou seja, 68% mais rápido que a mediana. Os nomes dos provedores estão nos dados publicados pela StarSling; os valores aqui são lidos no momento do build a partir de reports/providers/sources/performance-bar/starsling-metrics.tsv, gerado desses dados pelo analyse.py, que fica ao lado.
O que ele não diz
- A nossa foi feita sem mais nada ocupado na máquina; as deles, com o que quer que os hosts deles carregassem naquele dia. Uma máquina ocupada reduz a pontuação: em um 9950X com outras 1.25 vCPUs ocupadas para cada um de seus núcleos, a mesma suíte marcou 10.4 no nosso sandbox (8 de outubro de 2026). Esses vizinhos rodavam o mesmo teste em loop, a carga que mais consome cache, mais pesada que a de uma frota real.
- É um benchmark de um único tipo de trabalho, o Node.js executando ferramentas JavaScript, que acompanha a velocidade dos núcleos. Ele não diz nada sobre discos ou redes.
Os arquivos
sandboxd/bench/results/2026-10-10-cvt-01-accept/: o teste de aceitação, a saída bruta e oresults.jsonreports/providers/sources/performance-bar/starsling-metrics.tsvreports/providers/sources/performance-bar.md: como a cópia foi feita e lidasandboxd/bench/results/README.md: seções 40 e 42
Onde estão os resultados brutos
Cada caminho desta página é um arquivo do próprio repositório do Glac, ao lado do código que fez a medição. O repositório não é público; os caminhos dizem de qual rodada vem cada número, e o relatório de cada rodada diz o que foi executado, em quê e o que deu errado.