RPCパフォーマンスのベンチマーク方法

Alchemyは複数のRPCプロバイダーからブロックチェーンデータを取得し、開発者向けのダッシュボードやツールを提供しています。

ベンチマーク数値は引用しやすく、誤読もしやすい。これはRPCのパフォーマンスについて特に当てはまる。1つのレイテンシチャートの裏には、リクエストがどこから発行されたか、どのメソッドが実行されたか、どんなペイロードが送られたか、何をもって成功とみなしたか、失敗はどう扱われたか、そして1回のRPC呼び出しを測定したのかアプリケーション全体のワークフローを測定したのか、といった複数の異なる問いが隠れている。

私たちが公開EVM読み取りベンチマークを構築したのは、これらの詳細を可視化するためだ。目的は、統制された再現可能なテスト環境のもとで、プロバイダー間の違いを示すことにある。

このベンチマークが答えるのは、選択されたチェーン、リージョン、時間枠において、一般的なEVM JSON-RPC読み取りメソッドでプロバイダーがどう比較されるか、という問いだ。

これらはメソッド単位のインフラベンチマークであり、メソッド、チェーン、プロバイダー、リージョンごとに個別に実行される統制された手法だ。測定対象は個々のRPCリクエストであり、ウォレットのポートフォリオ読み込み、スワップの準備、複数回の呼び出しにまたがるトランザクションステータスのポーリングといった、アプリケーション全体のワークフローではない。この違いは重要だ。メソッド単位の結果は開発者がプロバイダーの挙動を比較する助けにはなるが、どんな本番アプリの完全なモデルでもない。

AlchemyのパブリックEVM読み取りベンチマークとは何か

Alchemyの公開EVM読み取りベンチマークは、RPCプロバイダーが設定済みのEVM JSON-RPC読み取りリクエストにどう応答するかを測定する統制されたテストだ。成功レスポンスのレイテンシ(平均、p50、p95)、成功率、失敗リクエスト数を取得し、プロバイダー、チェーン、メソッド、リージョン、時間枠ごとにグループ化する。

レイテンシは成功レスポンスのみから算出する。失敗した試行とタイムアウトは、成功率と失敗リクエスト数を通じて別途追跡される。これにより、どちらか一方の指標だけを見るのではなく、速度と信頼性の両方にベンチマークの焦点が保たれる。

定義と測定ルール

以降の内容の土台となる定義、セットアップ、ルール。各行は後述のセクションで詳しく説明する。

ベンチマークは何をカバーしているか

このベンチマークはEthereum、Optimism、Arbitrum、Base、World Chainの各メインネットをカバーしており、対象のプロバイダーにはAlchemy、dRPC、Infura、QuickNodeが含まれる。これらを選んだのは、広く使われているEVMメインネットと、開発者が最もよく比較検討するRPCプロバイダーをカバーするためであり、今後セットを拡張する余地も残している。あるメソッドについて、すべてのプロバイダーが同一の設定済みJSON-RPCリクエストを受け取る。

テストは統制されたAWS ECSリージョン、US East、US West、EU Central、AP Southeastから実行する。1つのリージョン内では、すべてのプロバイダーが同じランナーの場所からテストされる。ネットワーク上の距離がレイテンシを変化させうるためだ。もし1つのプロバイダーをバージニアから、別のプロバイダーをシンガポールからテストすれば、その結果はプロバイダーの性能と同じくらい地理的要因を反映してしまう。

各結果は以下でグループ化される。

• プロバイダー
• チェーン
• メソッド
• リージョン
• 直近の時間枠

ベンチマークは各プロバイダーに何を送るのか

メソッドとは、eth_getBalanceやeth_getLogsのような、呼び出される操作そのものを指す。ペイロードとは、そのメソッドを実行するために送る完全なリクエストで、パラメータを含む。この区別が重要なのは、パフォーマンスが両方に依存するからだ。軽量な参照と大規模な範囲スキャンではプロバイダーにかかる負荷がまったく異なり、1つのメソッドであっても入力によって結果が変わりうる。

あるメソッドについて、すべてのプロバイダーは標準の有料アカウント上で、同一の設定済みJSON-RPCペイロードを受け取る。これが公平性のルールだ。同じメソッド、同じパラメータ、同じチェーン、同じリージョン、同じタイムアウト、同じ成功基準であり、どのプロバイダーにも特別扱いはない。

現時点では、ほとんどのチェーンで7種類、Ethereumでは8種類の設定済みテストを実施している。

• eth_getBalance: アカウント残高の参照
• eth_getBlockByNumber(earliestブロック): チェーン開始地点でのヘッダー読み取り
• eth_getBlockByNumber(latestブロック): チェーン先頭でのヘッダー読み取り
• eth_getLogs: 1ブロック範囲
• eth_getLogs: 10ブロック範囲
• eth_getLogs: 100ブロック範囲
• eth_getLogs: 1,000ブロック範囲(Ethereumのみ)
• eth_getTransactionReceipt: 単一のトランザクションレシート参照

ペイロードの中にはチェーンの進行に合わせて動くものがある。例えば、latestブロックタグを使う呼び出しは、チェーンが進むにつれて変化する。一方、固定の過去データを使うものもある。Ethereumのeth_getLogsテストは、LINKトークンコントラクトについて設定済みの過去ブロック範囲を使用する。

この組み合わせは意図的なものだ。

• 固定入力はテストの一部を再現可能にする。
• 変動入力はテストの一部をライブのチェーン状態に沿ったものにする。
• 固定の過去入力はプロバイダーにとってキャッシュしやすい可能性がある。

RPCのパフォーマンスは、メソッド、パラメータ、ブロック範囲、レスポンスサイズ、キャッシュの挙動、チェーンの状態によって大きく変動しうる。ベンチマークを読む際は、自分のワークロードに最も近いメソッドとパラメータに注目してほしい。

パフォーマンスはどう測定されるか

パフォーマンスは2つの指標を通じて測定され、それぞれ異なる問いに答える。レイテンシは成功レスポンスがどれだけ速く返ってくるか(平均、p50、p95として報告)、成功率はリクエストがそもそもどれだけの頻度で成功するか(その背後にある失敗リクエスト数とともに)。

この2つは関連してはいるが別物だ。速い成功レスポンスと、信頼できるレスポンスは同じではない。どちらか一方が他方を隠してしまわないよう、両方を並べて報告している。

レイテンシはどのように測定されるか

レイテンシとは、成功したJSON-RPC HTTP POSTについて、ランナー側で計測したリクエストとレスポンスの時間だ。タイマーはランナーがリクエストを送信した時点で開始し、レスポンスを受け取った時点で停止する。あるプロバイダーが120ミリ秒で有効なレスポンスを返せば、そのリクエストのレイテンシは120msとなる。

私たちはウォームアップ済みの、再利用されるHTTP接続を使用する。平たく言えば、DNS参照、TCP接続の確立、TLSハンドシェイクといった、新しい接続を開くための最初のセットアップ手順は計測していない。ランナーはまず接続をプライミングし、その後プールされたkeep-alive接続上でPOST自体を計測する。

これにより、このレイテンシ数値は、クライアントが接続を再利用するのが一般的な、反復的なアプリケーショントラフィックに近いものになる。同時に、これらの数値をコールドな初回リクエストのレイテンシとして読むべきではないことも意味する。

レイテンシの分布に入るのは成功レスポンスのみだ。リクエストがタイムアウトした場合、HTTPエラーを返した場合、JSON-RPCエラーオブジェクトを返した場合、パースに失敗した場合、あるいはネットワークエラーが発生した場合は、代わりに失敗した試行としてカウントする。

タイムアウトは8,000msの遅いレスポンスとしては扱われない。レイテンシからは除外し、成功率でカウントする。これにより、レイテンシは応答速度に、成功率は信頼性に、それぞれ焦点を保つ。

成功率とは何か

成功率とは、試行されたリクエストのうち、ベンチマークのルールに従って成功した割合だ。成功リクエスト数を総試行リクエスト数で割って算出する。

リクエストが成功とみなされるのは、以下すべてを満たした場合のみだ。

1. ベンチマークのタイムアウト以内に完了する。
2. HTTP 2xxステータスを返す。
3. レスポンスボディがJSONとしてパースできる。
4. JSON-RPCレスポンスに、nullでないerrorオブジェクトが含まれない。

失敗した試行を隠すためにリトライは使わない。1回の試行リクエストにはチャンスは1回だけだ。失敗すれば、その失敗はカウントされる。

ベンチマークはタイムアウトをどう扱うか

ベンチマークのランナーは、各プロバイダーからの有効なレスポンスを最大8秒待つ。時間内に有効なレスポンスが返ってこなければ、その試行をタイムアウト失敗として記録する。

この8秒という打ち切り値は、私たちのテスト設定の一部だ。チェーン側で定められたものではなく、プロバイダーが内部で使っているかもしれない何らかのタイムアウトでもない。

この8秒の打ち切りは、現在すべての公開EVM読み取りメソッドに適用されている。メソッドごとに異なるタイムアウトを設定することも可能だが、現時点ではそのようなメソッドはない。

失敗リクエストとは何か

失敗した試行はレイテンシとは別に追跡している。以下のいずれかに該当するリクエストは失敗としてカウントする。

• 403、429、500、502、503、504といった非2xxのHTTPステータスを返す
• JSON-RPCエラーオブジェクトを返す
• 8秒後にタイムアウトする
• ネットワークレベルで失敗する
• 有効なJSONとしてパースできない

レート制限によるレスポンスも失敗としてカウントし、失敗した試行を成功に変えるためにリトライを使うことは一切ない。それぞれの失敗は、該当するメソッド、チェーン、リージョン、時間枠におけるプロバイダーの成功率を下げ、失敗リクエスト数を加算する。

各指標はどう定義されているか

なぜレイテンシと成功率を一緒に報告するのか

速いレスポンスは、実際にレスポンスが返ってきて初めて意味を持つ。あるプロバイダーは、成功したリクエストについては低いレイテンシを示しつつ、より高い頻度でタイムアウトや失敗を起こしている場合がある。だからこそ、レイテンシは成功率と並べて報告している。レイテンシは有効なレスポンスがどれだけ速く返るかを示し、成功率はそもそもどれだけの頻度で返るかを示す。

例えば、1,000回の試行を送り、そのうち990回が8秒のタイムアウト以内に成功して返ってきたとすれば、成功率は99%となる。失敗した10回の試行は、p50、p95、平均レイテンシには入らない。これらは信頼性の失敗として表れる。

これにより、2種類の誤読を防げる。レイテンシが低いが失敗が多いプロバイダーを速度だけで判断すべきではないし、成功率が高いがテールレイテンシが遅いプロバイダーを信頼性だけで判断すべきでもない。

なぜベンチマークは直近の時間枠を使うのか

このベンチマークは継続的に実行されている。一般的な公開EVM読み取りメソッドはおよそ10秒ごとに実行され、公開ベンチマークページは直近24時間の時間枠をもとに5分ごとに更新される。

稼働率が100%であれば、10秒ごとに実行されるメソッドは、プロバイダー、メソッド、ネットワーク、リージョンごとに1日あたり約8,640回の試行を生む。直近24時間の時間枠を使うことで、ページの鮮度を保ちながら、各公開数値が一回限りの変動をならせるだけの十分なサンプル数を確保できる。

したがって、この公開ページは1回のリクエスト、1回限りのテスト、あるいは瞬間的なスナップショットとしてではなく、日次の推移を示すものとして読んでほしい。

ベンチマークが測定していないものは何か

現時点で、このベンチマークは統制された条件下でのウォームな単一メソッドの読み取り性能を測定している。以下は測定していない。

• 複数回の呼び出しをまたぐユーザーフロー
• 書き込みトランザクションやトランザクションの送信
• WebSocketやサブスクリプションの挙動
• 顧客固有のリクエストの混合パターン
• コールドな初回リクエストの接続確立
• すべてのプロバイダー、チェーン、リージョン、メソッド、ペイロードの形状
• あなた自身のアーキテクチャ、トラフィック量、デプロイ地域の正確な挙動

この境界こそが、このベンチマークを有用なものにしている。どこまでこの数値が当てはまり、どこから自分自身のワークロード固有のテストを実行すべきかを示しているからだ。

速度と信頼性は関連してはいるが別の問いだ。

• 速度は、成功したリクエストがどれだけ速く返るかを問う。
• 信頼性は、リクエストがどれだけの頻度で成功して返るかを問う。

私たちはこの区別を1つの「最速プロバイダー」という主張に押し潰すのではなく、はっきり示すようにベンチマークを設計した。

開発者はこの結果をどう活用すべきか

公開ベンチマークは、プロバイダーを評価する際の出発点として使ってほしい。実践的な読み方のパターンは以下の通りだ。

1. 自分のワークロードに最も近いチェーンとメソッドを選ぶ。
2. 自分のユーザーやインフラがいるリージョンに最も近いものを比較する。
3. 平均やp50だけでなく、p95も確認する。
4. レイテンシと並べて成功率を確認する。
5. 自分のワークロードが異なるペイロード、より高い並行性、書き込み、WebSocket、複数回の呼び出しからなるフローを使っている場合は、判断する前にワークロード固有のベンチマークを実行する。

透明性のあるベンチマークは、より良い問いを立てる助けになる。何がテストされ、何がカウントされ、何が除外され、実際のアプリケーションにとって結果のどの部分が最も重要なのかを見極めやすくしてくれる。

よくある質問

AlchemyのパブリックEVM読み取りベンチマークとは何か

これは、RPCプロバイダーが一般的なEVM JSON-RPC読み取りリクエストをどう処理するかを測定する統制されたテストだ。選択されたプロバイダー、チェーン、メソッド、リージョンにわたって、成功レスポンスのレイテンシ(平均、p50、p95)、成功率、失敗リクエスト数を記録し、開発者がマーケティング上の主張ではなく、同一の再現可能な条件のもとでプロバイダーを比較できるようにしている。

RPCのレイテンシはどう測定されるか

レイテンシとは、1回のJSON-RPC POSTとそのレスポンスについて、ウォームアップ済みの再利用接続上でランナーが計測した実時間だ。タイマーはリクエストが送信された時点で開始し、有効なレスポンスが届いた時点で停止する。カウントされるのは成功レスポンスのみであり、レイテンシは接続確立や失敗ではなく、応答速度を反映する。

成功したリクエストとはどのような基準か

リクエストが成功とみなされるのは、8秒のタイムアウト以内に返り、HTTP 2xxステータスを返し、JSONとしてパースでき、JSON-RPCエラーオブジェクトを含まない場合に限られる。タイムアウト、HTTPエラー、レート制限によるレスポンスを含め、それ以外はすべて失敗した試行としてカウントされ、レイテンシからは除外される。

ベンチマークはタイムアウトをどう扱うか

ランナーは有効なレスポンスを最大8秒待つ。何も届かなければ、その試行は8,000msの遅いレスポンスとしてではなく、タイムアウト失敗として記録される。タイムアウトは成功率を下げるが、レイテンシを膨らませることは決してない。これにより速度と信頼性が別個の測定値として保たれる。

ベンチマークはリトライを使うか

いいえ。各測定は1回限りの試行だ。その試行が失敗すれば、リトライで取り繕うことなく失敗としてカウントされる。これにより、リトライが実アプリケーションで実際に発生する断続的な失敗を隠してしまうことを防ぎ、成功率の正直さが保たれる。

ベンチマークはどのチェーンとプロバイダーをカバーしているか

公開ベンチマークはEthereum、Optimism、Arbitrum、Base、World Chainの各メインネットをカバーしている。対象のプロバイダーにはAlchemy、dRPC、Infura、QuickNodeが含まれる。各プロバイダーは、あるメソッドについて、同じリージョンから、同じタイムアウトと成功基準のもとで、同一の設定済みリクエストを受け取る。

ベンチマークはどのRPCメソッドをテストしているか

このベンチマークは4つのEVMメソッドをもとに構成された7種類の設定済み読み取りテストを実行する。eth_getBalance、最も古いブロックと最新のブロックにおけるeth_getBlockByNumber、1ブロック・10ブロック・100ブロックの範囲にわたるeth_getLogs、そしてeth_getTransactionReceiptだ。Ethereumではさらに1,000ブロックのeth_getLogsテストが加わり、合計8種類となる。それぞれ固定のペイロードを使用するため、プロバイダー間で結果が比較可能な状態に保たれる。

ベンチマークが測定していないものは何か

アプリケーション全体のワークフロー、書き込みトランザクション、WebSocketのサブスクリプション、顧客固有のトラフィックの混合パターン、コールドな接続確立は測定していない。また、すべてのチェーン、プロバイダー、リージョン、メソッド、ペイロードをカバーしているわけでもない。こうしたケースについては、自分自身のトラフィックに合わせたワークロード固有のベンチマークを実行してほしい。

p95レイテンシの数値はどう読めばよいか

p95は次のように読む。このメソッド、チェーン、リージョン、時間枠において、成功レスポンスの95%はこの速さ以上であった、と。これは平均値では見えないテールの挙動を明らかにする。速いレスポンスは実際に返ってきて初めて意味を持つため、常に成功率と並べて読んでほしい。