測定方法
このサイトが実測値として示す数値、つまりスリープ、復帰、スナップショットと 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、2 層のメモリ、スリープ中のサンドボックスごとに待機させたプロセス、PCI 上のデバイス
- 呼び出し側
- 同じマシン上から、開いたままの 1 本の接続で呼び出すため、数値はハンドシェイクを含まないリクエストそのもの
| 項目 | 計測方法 | 中央値 | 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 |
| 作成から最初のコマンドの応答まで | 1 台ずつ順に 100 回 | 11.0 ミリ秒 | 12.0 ミリ秒 | 100 | tti-sequential.txt sequential x100 |
| 30 台同時：全台スリープ | 30 台のサンドボックスを同時にスリープさせ、最後の 1 台が終わるまで | 49.0 ミリ秒 | — | 1 | wake.txt concurrent 30 sleep_all |
| 30 台同時：全台復帰 | 同じ 30 台を同時に復帰させ、最後の 1 台が終わるまで | 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 ページ中 1 ページの 3 バイトだけが異なっていました。
ご自身のサンドボックスでも同じ数値を確認できます。サンドボックスを復帰させる必要があった API 呼び出しは、その所要時間をミリ秒単位で Server-Timing: wake;dur=… ヘッダーに返します。
CPU：StarSling のオープンベンチマーク
StarSling は、サンドボックスプロバイダーのオープンなベンチマークを公開しています（github.com/starslingdev/hpc-sandbox-benchmarks）。その CPU スコアは、4 vCPU、8 GiB のサンドボックスで Node.js の Web ツール群を実行したときの 1 秒あたりの実行回数です。そのスイートを Glac のサンドボックスで実行し、手元にあるデータのコピーに含まれる最新の公開実行のプロバイダーと結果を比較しました。
- Glac（1 秒あたりの実行回数）
- 29.0
- 13 社のプロバイダーの中央値
- 17.26
- その中央値より高速
- 68%
Glac の数値
- Glac 初の本番サーバー（英国コベントリー、AMD Ryzen 9 9950X、128 GB）で、2026年10月10日、受け入れテスト中に、ほかのサンドボックスが動いていない状態で測定しました。
- StarSling 自身のスイートとイメージ（
sandbox-benchmarks-toolchain:v8）を、4 vCPU、8 GiB のサンドボックスで、製品と同じ方法で実行しました。 - スイートを 3 回通して実行しました。各回の値は 3 回の試行の中央値で、28.97, 29.27, 29.00 です。掲載している数値はその中央値の 29.00 です。
他社の数値
- StarSling の実行 36498291449：2026年10月2日に Glac がデータのコピーを取得した時点でリーダーボードに表示されていた実行で、そのコピーに含まれる 9 回の実行（2026年9月23日〜29日）のうち最新のものです。
- 各プロバイダーの値は、サンドボックスごとの試行の中央値を、そのプロバイダーの全サンドボックスについてとった中央値です。リーダーボード自身のルールに従っています。
- Glac が保存したコピーは、各値を同じ実行内の 1 社のプロバイダーの値に対する比率として小数点以下 3 桁で保持しています。そのため、以下の各値と StarSling 自身の値との差は約 0.02 以内です。
Glac の値と 13 社の値（1 秒あたりの実行回数、高い順）
29.0 ÷ 17.26 = 1.68 なので、中央値より 68% 高速です。プロバイダー名は StarSling の公開データにあります。ここでの値は、そのデータから隣の analyse.py で作成した reports/providers/sources/performance-bar/starsling-metrics.tsv を、ビルド時に読み込んだものです。
この結果からわからないこと
- Glac の測定はマシン上でほかに何も動いていない状態で行いましたが、他社の測定は、その日にホストが抱えていた負荷の下で行われています。マシンが混んでいるとスコアは下がります。コアごとにほかのビジーな vCPU が 1.25 個ある 9950X では、同じスイートが Glac のサンドボックスで 10.4 でした（2026年10月8日）。このとき隣で動いていたのは同じテストのループで、考えうる中で最もキャッシュを消費する負荷であり、実際のフリートより重いものです。
- これは 1 種類の処理、つまり 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 自身のリポジトリ内のファイルで、測定に使ったコードと同じ場所にあります。リポジトリは公開していませんが、パスから各数値がどの実行によるものかがわかります。また各ラウンドのレポートには、何をどのマシンで実行し、何がうまくいかなかったかが書かれています。