我們如何測量
本站列為實測的數字，都是在裸機上、用我們正式環境伺服器所用的處理器測得：休眠、喚醒和快照，以及 CPU 基準測試。以下逐一列出，附上機器、日期、測量方式和原始結果的位置。
- 裸機。 一整台實體機器，而不是別人機器上的虛擬機器，所以沒有我們看不到的東西和它共用。
- 中位數，附上分布。 多次執行的中間值，旁邊附上第 95 百分位數和執行次數。
- 最佳情況就標明是最佳情況。 這些測試大多在機器上沒有其他工作時執行；凡是如此，頁面上都會註明。
- 保留原始結果。 每個數字都註明讀取自哪個檔案，檔案和產生它的程式碼一起放在儲存庫中。
休眠、喚醒和快照
- 機器
- Cherry Servers，新加坡：AMD Ryzen 9 9950X（Zen 5，16 核），128 GB，Ubuntu 26.04.1，Linux 核心 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 個：全部休眠 | 三十個沙箱同時進入休眠，計到最後一個為止 | 49.0 毫秒 | — | 1 | wake.txt concurrent 30 sleep_all |
| 同時 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 分數是在 4 vCPU、8 GiB 的沙箱中執行 Node.js Web 工具鏈，以每秒執行次數計。我們在 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 自己儲存庫中的檔案，和進行測量的程式碼放在一起。儲存庫並未公開；路徑說明每個數字來自哪一次執行，每一輪的報告則說明跑了什麼、在什麼機器上跑，以及出了什麼問題。