我们如何测量
本站作为实测给出的数字，都是在裸金属上、用我们生产服务器所用的处理器测得的：休眠、唤醒、快照，以及 CPU 基准测试。下面逐一列出，附机器、日期、测量方法和原始结果的位置。
- 裸金属。 一整台物理机器，而不是别人机器上的虚拟机，所以不会有我们看不见的负载和它共用资源。
- 取中位数，并给出离散程度。 多次运行的中间值，旁边附第 95 百分位数和运行次数。
- 最好情况会注明。 这些测试大多在机器上没有其他负载时运行；凡是这种情况，页面都会注明。
- 保留原始结果。 每个数字都注明了读取自哪个文件，这个文件和生成它的代码放在同一个仓库里。
休眠、唤醒和快照
- 机器
- Cherry Servers，新加坡：AMD Ryzen 9 9950X（Zen 5，16 核），128 GB，Ubuntu 26.04.1，内核 7.0.0-34
- 日期
- 2026年10月3日
- 沙箱
- 4 vCPU / 8 GiB 沙箱，node:24-bookworm
- 节点
- sandboxd，采用当天的默认配置：打过补丁的 Firecracker、两层内存、为每个休眠的沙箱预备一个进程、设备走 PCI
- 调用方
- 在同一台机器上，通过一个保持打开的连接，所以数字就是请求本身的用时，不含握手
| 测量项 | 计时方式 | 中位数 | p95 | 次数 | 数据来源 |
|---|---|---|---|---|---|
| 进入休眠 | POST …/sleep，按调用方看到的时间 | 2.3 毫秒 | 2.8 毫秒 | 30 | wake.txt cycle sleep |
| 唤醒（自行进入休眠之后） | 节点自己统计的恢复用时（见其 Server-Timing 响应头），针对下一次调用 | 3.5 毫秒 | 3.9 毫秒 | 29 | wake.txt auto wake |
| 那次调用收到响应 | 唤醒它的整个请求，从发出到收到响应 | 6.7 毫秒 | 7.1 毫秒 | 29 | wake.txt auto call |
| 唤醒（刚进入休眠就唤醒） | 为下次唤醒预备的进程还在启动，所以要等它 | 5.6 毫秒 | 6.3 毫秒 | 30 | wake.txt cycle wake |
| 为运行中的沙箱创建快照 | 通过 API：内存、进程和磁盘，在运行中完成 | 32 毫秒 | — | 4 | snapshot.txt 31.5 to 31.9 ms |
| 创建（从预热池） | 一份已在运行的模板副本 | 1.3 毫秒 | — | 100 | tti-sequential.txt create median |
| 创建（到第一条命令返回） | 一个接一个，共一百次 | 11.0 毫秒 | 12.0 毫秒 | 100 | tti-sequential.txt sequential x100 |
| 30 个同时休眠 | 30 个沙箱在同一时刻进入休眠，计到最后一个完成 | 49.0 毫秒 | — | 1 | wake.txt concurrent 30 sleep_all |
| 30 个同时唤醒 | 同样这 30 个在同一时刻唤醒，计到最后一个完成 | 61.4 毫秒 | — | 1 | wake.txt concurrent 30 wake_all |
文件在 sandboxd/bench/results/2026-10-03-s3-ryzen9950x/4c8g-layers-final/ 中；报告是 sandboxd/bench/results/README.md 第 2 轮的“二”一节。本站其他页面的休眠和唤醒数字（唤醒 3.5 毫秒，休眠 2.3 毫秒）读自和本表同一个文件，所以都是这一轮的。快照与 Firecracker 自己写出的完整内存逐页做了核对：2,097,152 页中有一页的 3 个字节不同。
你自己的沙箱也能读到同样的数字：每个需要唤醒沙箱的 API 调用，都会在其 Server-Timing: wake;dur=… 响应头里给出唤醒用时，单位为毫秒。
CPU：StarSling 的开源基准测试
StarSling 发布了一个沙箱服务商的开源基准测试 (github.com/starslingdev/hpc-sandbox-benchmarks)。它的 CPU 得分是 Node.js Web 工具链在 4 vCPU、8 GiB 沙箱中的成绩，单位是每秒运行次数。我们在 Glac 沙箱里运行了它的测试套件，并把结果与我们所存数据中它最新一次公开运行里的各家服务商作比较。
- Glac，每秒运行次数
- 29.0
- 13 家服务商的中位数
- 17.26
- 比该中位数快
- 68%
我们的成绩
- 我们的第一台生产服务器，位于英国考文垂：AMD Ryzen 9 9950X，128 GB 内存；2026年10月10日验收测试期间测得，当时机器上没有其他沙箱在运行负载。
- StarSling 自己的测试套件和镜像 (
sandbox-benchmarks-toolchain:v8)，在 4 vCPU、8 GiB 的沙箱中，按产品自身的方式运行。 - 测试套件跑了三遍，每遍取其三次试验的中位数：28.97, 29.27, 29.00。最终数字是这三者的中位数，29.00。
其他服务商的成绩
- StarSling 编号 36498291449 的运行：2026年10月2日我们复制它的数据时，排行榜上显示的就是这次运行；它也是那份数据中九次运行里最新的一次（2026年9月23日至29日）。
- 一家服务商的数值，是先取它每个沙箱各次试验的中位数，再取这些沙箱之间的中位数：这是排行榜自己的规则。
- 我们保存的数据把每个数值记为同一次运行中某一家服务商数值的比值，保留三位小数，所以下面每个数值与 StarSling 自己的数值相差约 0.02 以内。
我们的成绩与那 13 个数值（每秒运行次数，从高到低）
29.0 ÷ 17.26 = 1.68，即比中位数快 68%。服务商的名字见 StarSling 公开的数据；这里的数值在构建时读自 reports/providers/sources/performance-bar/starsling-metrics.tsv，它由旁边的 analyse.py 根据那份数据生成。
它说明不了什么
- 我们的测试在机器上没有其他负载时运行；他们的则运行在宿主机当天承载的各种负载之上。机器繁忙会拉低得分：在一台每个核心另有 1.25 个忙碌 vCPU 的 9950X 上，同一套件在我们的沙箱中得分 10.4（2026年10月8日）。那些邻居循环运行的是同一个测试，这是最吃缓存的负载，比真实集群的负载更重。
- 这只是针对一种工作的一项基准测试：Node.js 运行 JavaScript 工具，成绩随核心速度变化。它不反映磁盘或网络的情况。
原始文件
sandboxd/bench/results/2026-10-10-cvt-01-accept/：验收测试、它的原始输出和results.jsonreports/providers/sources/performance-bar/starsling-metrics.tsvreports/providers/sources/performance-bar.md：这份数据是如何复制和读取的sandboxd/bench/results/README.md：第 40 和 42 节
原始结果在哪里
本页的每个路径都是 Glac 自己仓库里的一个文件，和进行测量的代码放在一起。仓库并不公开；这些路径说明每个数字来自哪次运行，每一轮的报告写明了运行了什么、在什么上运行，以及出了什么问题。