Solana gRPCのパフォーマンス：公開ベンチマーク手法

Solanaのパフォーマンス数値の価値は、その背後にある手法で決まります。リージョン、期間、テスト構成が示されていないレイテンシの数値は、検証も比較も再現もできません。

この記事では、私たちがSolana gRPCストリームをどのように測定しているかを説明し、その測定で得られた数値を公開します。また、私たちのものを含む任意のエンドポイントに対してテストを再現するための完全な構成も掲載します。

なぜ手法を公開するのか？

レイテンシの数値が1つだけでは、テストをどこで実行したのか、何を購読したのか、どのコミットメントレベルで、どの期間に測定したのかが分かりません。Solanaではこうした詳細が数値を左右します。ブロックは1秒未満で届き、ストリーミングエンドポイント間の差は数ミリ秒しかありません。私たちはすでにリクエストベンチマークの測定ルールを公開しており、この記事ではSolanaのストリーミングについて同じことを行います。

リクエストベンチマークであれば、同じリクエストを送れば誰でも妥当性を確認できます。ストリームはそれより検証が困難です。チェーン上のある瞬間のアクティビティを再生して、プロバイダーがそれを迅速に、漏れなく、順序どおりに配信したかを確認することはできません。手法が公開されていれば、開発者は特定の当事者を信頼する代わりに、自分のワークロードでテストを再実行できます。

このベンチマークは何を測定するのか？

ストリーミングのパフォーマンスは、3つの別々の問いに分かれます。データがいつ届くか、データがすべて届くか、そして接続が切れたときに何が起こるかです。このベンチマークは、そのうち最初の問いにリージョンごとに答えます。

• ネットワーク往復（p50）：ランナーからエンドポイントへのTCP接続時間の中央値で、30回の接続から算出します。主に地理的な距離で決まるため、データが流れる前の時点で、その場所にいることのコストが分かります。
• 配信のばらつき（p90、p99）：遅いメッセージや最悪ケースのメッセージが、その実行で最も速かった配信より何ミリ秒遅れて届くかを示します。システムが最も苦しい瞬間に体感するのはテール部分です。清算モニターにとっては、典型的な更新が速くても、重要な1件が遅れて届けば意味がありません。

どちらもリージョンごとに報告し、単一のグローバル平均としては報告しません。

時刻を信頼せずにストリームの時間をどう測るのか？

リクエストの時間測定は簡単です。1台のマシンがリクエストを送信して応答を受け取るので、1つの時計で往復全体をカバーできます。

ストリームではこの利便性が失われます。イベントはバリデータで発生し、プロバイダーのインフラを経由して、別のデータセンターにある別のマシン上のサブスクライバープロセスに届きます。ここでは2つの時計が関わり、別々のマシンの時計は、どちらもNTPを使っていても数ミリ秒ずれることがあります。適切に運用されたエンドポイント間の配信差はそれより小さい場合があるため、単純なタイムスタンプ計算ではパフォーマンスではなく時計の誤差を測定してしまうおそれがあります。

私たちのエンドポイントは各メッセージに生成時刻を記録し、ランナーはメッセージの到着時刻からその時刻を差し引きます。この減算は2つの時計を比較することになるため、ランナーは各実行の前後に公開タイムサーバーと自身の時計を照合します。それでも小さな固定誤差が残る可能性があります。各メッセージをその実行で最も速かった配信を基準にして報告すると、この誤差は取り除かれます。固定の時計誤差はすべてのメッセージを同じ量だけずらすため、減算で相殺されるからです。往復の列は補正を必要としません。ランナーが各TCP接続を自身の時計で計測しているためです。

これらの数値は、バリデータからプロセスまでの合計時間を示すものではなく、プロバイダーの順位付けでもありません。順位付けには、同じマシンから2つのストリームを比較するという別のテストが必要で、それについては再現のセクションで説明します。

測定の公正さを保つための詳細が2つあります。コミットメントレベルは最も早い確認レベルであるprocessedに固定しています。コミットメントレベルを混在させると、イベントのライフサイクルの異なる時点を測定することになるためです。また、チェーン自体のブロックタイムスタンプは計算に一切使用しません。Solanaは1秒未満でブロックを生成しますが、ブロックタイムスタンプの分解能は秒単位しかなく、ミリ秒単位の差を捉えるには粗すぎます。

テストの実行はどのようなものか？

この記事のすべての数値は、以下の構成の実行から得られたものです。構成が変わった場合は、数値をその場で編集するのではなく、新しい日付で再公開します。

• テスト対象のストリーム：1回の実行につき、Yellowstone互換のgRPCトランザクションストリーム1本。
• 監視対象のアカウント：PumpSwap（PumpのAMMプログラム）pAMMBay6oceH9fJKBRHGP5D4bD4sWpmSwMn52FMfXEA。トランザクション量が多いことから選定しました。
• コミットメントレベル：すべての実行でprocessed。
• サンプルサイズ：リージョンごとに20,000トランザクション。
• 計測地点：6つのクライアントリージョン（米国東部、米国西部、欧州西部、欧州中部、シンガポール、東京）のFlyマシン上のランナー。各ランナーからエンドポイントへの往復時間も結果に含めています。カフェから実行したベンチマークは、カフェを測定することになるからです。
• クライアント：geyserbenchのRust製latencyサンプルを、デフォルトのクライアント設定とTLSで使用。下の再現セクションで示します。
• 期間：2026年10月14日〜16日。公開するすべての表に、その元になった実行の日付を記載します。

結果はどうだったか？

各リージョンのクライアントから測定した、Solana gRPCストリームの配信特性です。各行は、processedコミットメントの単一ストリームで20,000トランザクションを測定したもので、2026年10月14日〜16日に実行しました。

p50の列は、ランナーからエンドポイントまでのネットワーク往復時間の中央値です。p90とp99の列は、遅いメッセージや最悪ケースのメッセージが、その実行で最も速かった配信より何ミリ秒遅れて届くかを示します。

p50は所在地による距離のコスト、p90とp99は配信の安定性として読んでください。どちらもバリデータからのエンドツーエンドの合計レイテンシではありません。自分の期待値を見積もるには、自分のリージョンの行を見るのが適切です。フランクフルトの開発者は、最も速くテストされたリージョンに引っ張られたグローバル平均ではなく、欧州中部の行を見てください。Solana gRPCをローンチした際、私たちはこの主張の初期版を公開しました（us-east-1から測定し、他の選択肢より平均5〜15ms速い配信）。この表は、その単一リージョンでの直接比較のスナップショットを複数リージョンに発展させたもので、異なる、かつ補完的な指標を用いています。

どうすれば再現できるのか？

必要なのはRustと、Solana gRPCにアクセスできるAlchemyのAPIキーです（前提条件はクイックスタートに記載しています）。コマンドは3つです。

これはSolana gRPCストリームを1本開き、トランザクションの多いアカウントでprocessedコミットメントの20,000トランザクションを監視して、エンドポイントまでのネットワーク往復時間の中央値を出力します。続いて、p50、p90、p99のメッセージが最も速い配信より何ミリ秒遅れて届いたかを出力します。対象とするリージョンのサーバーで実行し、上の表と比較してください。

私たちはpAMMBay6oceH9fJKBRHGP5D4bD4sWpmSwMn52FMfXEA（PumpSwap、PumpのAMMプログラム）を使用しました。トランザクション量が非常に多く、20,000トランザクションがすぐに集まるため適しています。別のプログラムを監視する場合や短いテストを実行する場合は、ACCOUNTにプログラムアドレスを、Nにトランザクション数を設定します。

1つのプロバイダーを測定するのではなく2つのプロバイダーを比較するには、同じマシンから両方のストリームを実行し、各トランザクションをどちらが先に配信したかを記録します。公開されているgeyserbenchは、両方のエンドポイントを記載した1つの設定ファイルでこれを行い、それぞれがトランザクションを先に検出した頻度を報告します。

これを実行して私たちの数値と大きく異なる結果が出た場合は、お知らせください。それを知るために手法を公開しています。

このベンチマークで測定しないものは何か？

次の3点は、意図的にこのベンチマークの対象外としています。

• ストリームの信頼性：これはレイテンシのベンチマークです。イベントの欠落、切断、再接続時間、再接続後のバックフィルは測定しないため、それらについては良くも悪くも何も示しません。アプリケーションがギャップのない配信に依存している場合は、直接テストしてください。私たちのエンドポイントは48時間分の履歴（400,000スロット以上）を保持しており、再接続したクライアントはfrom_slotでそこからリプレイできます。
• トランザクションのランディング：トランザクションをブロックに含めることは書き込み経路の問題であり、独自のインフラと独自の障害モードがあります。ここではそれについて何も示しません。
• リクエスト/レスポンス型の読み取り：JSON-RPCメソッドのポーリングは、障害モードの異なる別のアクセスパターンです。リクエストトラフィックについては、私たちの公開RPCベンチマークが独自の公開ルールのもとで別途カバーしています。

よくある質問

AlchemyのSolana gRPCはどのくらい速いのか？

どこから測定するかによって異なります。そのためAlchemyは、単一のグローバルな数値ではなく、リージョンごとのレイテンシ分布を公開しています。上のリージョン別の表は、公開した手法により明記した日付で得られた、ネットワーク往復時間と、p90およびp99の配信のばらつきを示しています。エンドポイントまでのネットワーク往復時間は米国東部の1.8 msから欧州西部の21.9 msまでで、p99のメッセージはリージョンに応じて最も速い配信から6.8〜23.6 ms以内に届きます。

Solana gRPCのレイテンシはどのように測定しているのか？

各リージョンのクライアントがprocessedコミットメントでgRPCストリームを1本開き、トランザクション量の多いプログラムで20,000トランザクションを監視して、各メッセージの到着時刻と私たちのエンドポイントがそのメッセージを生成した時刻を比較します。結果はリージョンごとに、その実行で最も速かった配信に対するp90およびp99の遅延として報告し、クライアントからエンドポイントまでのネットワーク往復時間の中央値を併記します。

AlchemyのSolana gRPCベンチマークは再現できるのか？

はい。テストはgeyserbenchのlatencyサンプルで実行され、正確なコマンドはこの記事に掲載しています。サービスを提供するリージョンのサーバーでprocessedコミットメントで実行し、得られたパーセンタイルをリージョン別の表と比較してください。2つのプロバイダーを比較する場合は、geyserbenchで同じマシンから両方のエンドポイントを並行して実行することもできます。

ベンチマークではどのコミットメントレベルを使用しているのか？

すべての実行は、Solanaで最も早いコミットメントレベルであるprocessedで購読します。コミットメントレベルを混在させると、ライフサイクルの異なる時点でイベントを測定することになり、パーセンタイルが意味をなさなくなります。本番アプリケーションではconfirmedやfinalizedのほうが適している場合もあります。この手法では、リージョンや実行をまたいで数値を比較できるよう、コミットメントを一定に保っています。

これは他のプロバイダーとの比較なのか？

いいえ。この記事は、AlchemyがSolana gRPCのパフォーマンスをどのように測定し公開しているかを説明するものです。他のプロバイダーもそれぞれベンチマークを公開しており、この分野で公開される手法が増えることは誰にとっても有益です。再現のセクションは、重要な比較を自分のワークロードで自分自身で実行できるように用意しています。

Solanaデータのストリーミングを始める

私たちのSolana gRPCストリーミングはYellowstone互換なので、既存のクライアントの接続先を切り替えるのはURLの変更だけで済み、書き直しは不要です。料金は1TBあたり$75で、月額最低料金はありません。クイックスタートはYellowstone gRPCドキュメントで説明しています。Solana上で開発するチームは、2,000万ドルのSolana Fundを通じて最大25,000ドルのクレジットに応募することもできます。必要であれば、まずベンチマークを実行してください。そのためのベンチマークです。