WebAssembly コールド スタート: ベンチマークが示すもの

コールド スタートは再び、単なる学術研究の対象ではなく、WebAssembly ランタイム間の商業的な差別化の軸となっています。 Wasmer は、コールド ブートの問題に対する直接の答えとして提示された Instaboot と呼ばれる機能によって、これを明確なセールス ポイントにしています。

この反射は、バックエンド ベンチマーク方法論に関する記事ですでに文書化されている動的な動きをまさに思い出させます。: いくつかの競合ベンダーは、パフォーマンス数値を生成したプロトコルを常に指定せずに、自社の製品ページにパフォーマンス数値を表示しています。メソッドのないコールド スタートの数値は、メソッドのないレイテンシの数値にすぎません。

コールド スタートは単一の操作ではありません。これは異なるフェーズの合計であり、2 つのサプライヤーが同じ名前で同じフェーズを測定するとは限りません。

すでにメモリにロードされ、すでにコンパイルされているモジュールのインスタンス化のみをカウントする図は、ネットワークのロードとコンパイルを含む図よりも機械的に見栄えが良くなります。どちらもそれ自体は誤りではありません。問題は、2 つのどちらが測定されたかを特定せずに比較すると発生します。

近年、arXiv でプレプリントとして公開された学術研究では、さまざまなランタイムでの WebAssembly モジュールのインスタンス化時間を測定しました。これらの作業の共通点は収束する数字ではなく、テストされたランタイム、モジュールのサイズ、使用されるハードウェアに応じて大きな違いがあります。

私たちは自主的に、これらの出版物から取得した正確な数値をこの記事に含めることはありません。執筆時に各論文の方法論を徹底的に再確認せずに、孤立した数値を再公表すると、この記事で説明している問題が再現されることになります。つまり、実際に何を測定するのかを知ることを可能にするコンテキストのない数値です。

一方、この差異が学習することは直接役に立ちます。コールド スタートは、一般的な方法論の記事で説明した 環境パリティ の規律 (比較したすべてのシステムで同一のハードウェア、同じリージョン、同じキャッシュ状態) で思い出したとおり、測定コンテキストに強く依存します。

この議論で最も引用されている 3 つのスタンドアロン WebAssembly ランタイムは、コンパイル速度と実行パフォーマンスのバランスが同じではありません。これが、コールド スタートの数値が用語ごとに比較されない理由の一部を説明しています。

サーバーレスの議論で最も頻繁に対立する 2 つのランタイム間の完全なアーキテクチャの詳細については、専用の比較 Wasmtime と Wasmerを参照してください。

Wasmer が公に伝えている製品の位置付けによれば、Instaboot はリクエストごとに完全な起動を再開するのではなく、スナップショット メカニズムによってすでに初期化されているインスタンスを復元します。これは、対象とする問題と一致する、実際のアーキテクチャ上の選択です。

ただし、この記事では、Wasmer 製品ページに表示されているパフォーマンスの数値を繰り返すことはしません。この数値がどのようなハードウェア、どのようなワークロード、どのような測定プロトコルで生成されたのかが分からないまま、この数値を再公開すると、マーケティング数値を独立したベンチマーク結果として扱うという、まさに上記の間違いを犯すことになります。

Aurabase は、パイロット プロジェクトではなく、本番環境の Wasmtime でエッジ機能を実行します。まさにこの出願で認められる内容と、その主張がどこで終わるのかがここにあります。

依存関係は、dev-dependency やコメントではなく、サービスの実稼働依存関係で、有効化された機能 async および cranelift とともにハード宣言されます。

# リポジトリからの実際の抽出
[dependencies]

# WASM ランタイム
wasmtime = { version = "43", features = ["async", "cranelift"] }

このファイルに記載されていないこと: ベンチマーク方法論 で説明されているプロトコルに従って測定されたコールド スタートの数値は、現在このランタイムのリポジトリには存在しません。パーセンタイル、ハードウェア、ワークロードを細分化した日付の測定結果が公開されるまでは、製品の測定された特性として Aurabase の数値を引用すべきではありません。プラットフォームの一般的なアーキテクチャについては、柱となる記事 Aurabase Rust アーキテクチャを参照してください。コールド スタート WASM とコールド スタート コンテナーの具体的な比較については、ここで取り上げる方法論的な質問とは別に、専用記事 WASM vsコンテナーを参照してください。

リリース日のものも含め、コールド スタートのフィギュアに尋ねるべき 7 つの質問。

1. どのようなフェーズが含まれていますか? ネットワークの読み込み、検証、コンパイル、インスタンス化、最初の呼び出し: 一部のみをカウントした図は、それらすべてをカウントした図と比較できません。
2. モジュールは本当に「コールド」でしたか? すでにメモリまたはディスク キャッシュにあるモジュールは、初めてロードされたモジュールと同じことをテストしません。
3. JIT コンパイルまたはプリコンパイル済みアーティファクト (AOT)? 2 つの戦略には構造的に異なる初期コストがあります。
4. 1 桁ですか、それとも分布ですか? 10 回の実行で最高の実行は、1,000 回の実行での p95 と同じ値にはなりません。
5. 機器と地域は指定されていますか? ハードウェア仕様のない図は第三者による複製ができません。
6. 等しい負荷とトポロジでの比較? セルフホステッド ランタイムをレポートせずにマネージド サービスと比較すると、解釈が歪められます。
7. テストされたランタイムの日付とバージョン? 急速に進化しているプロジェクトの日付のない数字は、数か月後には何の意味も持ちません。