---
title: "自分のワークフローに合わせてRPCプロバイダーをベンチマークする方法"
description: "RPCプロバイダーは、負荷下のレイテンシー、ブロックラグ、データ整合性をそれぞれ分けて測定し、アプリが呼び出すメソッドで、アプリが動く場所からベンチマークする。"
---

# 自分のワークフローに合わせてRPCプロバイダーをベンチマークする方法

<ImageBlock
  src="https://media.alchemy.com/blog/how-to-benchmark-rpc-providers-hero-v3.jpg"
  alt="自分のワークロードでプロバイダーをベンチマークする"
  width={1024}
  height={480}
  priority
/>

RPCプロバイダーは、自分のワークロードに固有のベンチマークに基づいて選ぶべきだ。私たちは自社を含むプロバイダーを常にベンチマークしており、多くのチームが同じことをするのも見てきた。リクエストを送るのは簡単な部分だ。難しいのは、何を測るかを決め、その結果に実際に判断を委ねられるテストを組むことである。

だから私たちは方法論を書き起こし、それを実行するためにAlchemy rpcbenchを作った。任意のRPCプロバイダーの組み合わせを、自分のマシンから、アプリが実際に呼び出すメソッドでベンチマークする単一のバイナリだ。方法論そのものは、すでに使っているどのツールでも機能する。

測る価値があるのは三つ、負荷下のレイテンシー、ブロックラグ、データ整合性だ。それぞれがシステムの異なる部分を壊し、ある項目に強いプロバイダーが別の項目では遅れていることもある。そのため、混ぜ合わせたスコアは自分にとって重要な項目を埋もれさせる。アプリが実際に呼び出すものを、アプリが動く場所から測ること。

## RPCプロバイダーをベンチマークするとき、何を測るべきか?

負荷下のレイテンシー、ブロックラグ、データ整合性を、それぞれ分けて測定し報告する。

<EmbeddedTable
  table={{
    columns: [
      { key: "dimension", width: 160, title: "項目", dataType: "object" },
      { key: "what", width: 260, title: "測るもの", dataType: "object" },
      { key: "how", width: 360, title: "測り方", dataType: "object" },
    ],
    data: [
      {
        dimension: { title: "負荷下のレイテンシー", tooltip: "", icon: "" },
        what: {
          title:
            "リクエスト量が増えるにつれ、プロバイダーがどれだけ速く応答するか",
          tooltip: "",
          icon: "",
        },
        how: {
          title:
            "本番相当のRPSで何段階かテストを行う。各段階でp95とp99を読み、失敗率と429率を並べて見る",
          tooltip: "",
          icon: "",
        },
        id: 0,
      },
      {
        dimension: { title: "ブロックラグ", tooltip: "", icon: "" },
        what: {
          title: "プロバイダーが新しいブロックをどれだけ早く届けるか",
          tooltip: "",
          icon: "",
        },
        how: {
          title:
            "すべてのプロバイダーで同時に<code>newHeads</code>を購読する。各ブロックを誰が最初に通知したか、どれだけの差があったかを記録する",
          tooltip: "",
          icon: "",
        },
        id: 1,
      },
      {
        dimension: { title: "データ整合性", tooltip: "", icon: "" },
        what: {
          title: "ブロックが通知された瞬間に、そのデータを提供できるか",
          tooltip: "",
          icon: "",
        },
        how: {
          title:
            "新しいヘッドごとに、ブロック、ログ、レシート、トランザクションを要求する。それらが一致するかを確認する",
          tooltip: "",
          icon: "",
        },
        id: 2,
      },
    ],
  }}
/>

データ整合性は、ほとんどのチームが一度もテストしない項目だ。プロバイダーによっては、メソッドごとに異なるバックエンドから応答しており、それらは常に同時に進むとは限らない。そのため、新しいヘッドを通知しながら、同じブロックのログが不完全なまま返ってくることがある。本が棚に並ぶ前に蔵書目録を更新する図書館を想像してほしい。目録には新着本が入ったとあるのに、棚は空だ。

## どれを最初に測るべきか?

アプリがデータで何をするかに合うものから始める。新しいブロックに反応して動くなら、ブロックラグだ。ブロックが届いた瞬間にそのログや状態を読むなら、データ整合性だ。それ以外なら負荷下のレイテンシーである。Valantis、Aave、RedStone、Structのようなチームが、それぞれ異なるものを測るベンチマークを実行するのを私たちは見てきた。

<EmbeddedTable
  table={{
    columns: [
      {
        key: "building",
        width: 240,
        title: "構築しているもの",
        dataType: "object",
      },
      { key: "first", width: 260, title: "最初に測るもの", dataType: "object" },
      { key: "risk", width: 280, title: "リスク", dataType: "object" },
    ],
    data: [
      {
        building: {
          title:
            'DEXまたはオンチェーンの見積もりエンジン（例: <a href="/case-studies/how-valantis-built-a-reliable-trading-experience-on-hyperliquid">Valantis</a>）',
          tooltip: "",
          icon: "",
        },
        first: {
          title:
            "ブロックラグ、次に価格算出ロジックが行う<code>eth_call</code>の<strong>p99</strong>",
          tooltip: "",
          icon: "",
        },
        risk: {
          title:
            "すでに進んだブロックに基づいて価格を付けるか、スプレッドが閉じた後に見積もりが届く",
          tooltip: "",
          icon: "",
        },
        id: 0,
      },
      {
        building: {
          title:
            '清算機能を持つレンディングプロトコル（例: <a href="/case-studies/how-aave-runs-largest-lending-protocol-alchemy">Aave</a>）',
          tooltip: "",
          icon: "",
        },
        first: {
          title:
            "ブロックラグとデータ整合性、次にヘルスファクターと価格の読み取りの<strong>p99</strong>",
          tooltip: "",
          icon: "",
        },
        risk: {
          title:
            "清算が1ブロック遅れて実行されるか、そのブロックのデータが提供可能になる前にポジションを読んでしまう",
          tooltip: "",
          icon: "",
        },
        id: 1,
      },
      {
        building: {
          title:
            'オラクルまたはイベント駆動型サービス（例: <a href="/case-studies/how-redstone-keeps-price-feeds-reliable-across-51-chains">RedStone</a>）',
          tooltip: "",
          icon: "",
        },
        first: {
          title:
            "ブロックラグとデータ整合性、次に<code>eth_getLogs</code>と<code>eth_call</code>の<strong>p99</strong>",
          tooltip: "",
          icon: "",
        },
        risk: {
          title: "ログが不完全なまま返ってきたため、トリガーを見逃す",
          tooltip: "",
          icon: "",
        },
        id: 2,
      },
      {
        building: {
          title:
            'インデクサーまたはウォレットのバックエンド（例: <a href="/case-studies/how-struct-is-building-the-data-layer-for-onchain-finance">Struct</a>）',
          tooltip: "",
          icon: "",
        },
        first: {
          title:
            "ピーク時のレートでの<strong>p95</strong>と、それに並べた失敗率と429率",
          tooltip: "",
          icon: "",
        },
        risk: {
          title:
            "バックフィルが止まるか、ユーザーが取引している最中に残高が古くなる",
          tooltip: "",
          icon: "",
        },
        id: 3,
      },
    ],
  }}
/>

次に、プロバイダーをメソッドごとに一つずつ比較する。平均では速いプロバイダーでも、アプリが最も多く行う一つの呼び出しでは遅いことがあるからだ。その差がすべてを決める。スプレッドが閉じた後に届いた見積もりは、遅い見積もりではない。約定を逃したのだ。

## 信頼できるRPCベンチマークはどう実行するのか?

レイテンシーを測るには、固定のスケジュールでリクエストを送る。素直な設計は、リクエストを送り、応答を待ってから次を送るというものだが、これではプロバイダーが苦しみ始めたまさにそのときに、送るリクエストが静かに減る。テストは一定の負荷を保つべき瞬間に手を緩め、探していた速度低下はデータに一切現れない。代わりに固定のクロックで送信し、各送信がそのクロックからどれだけ遅れたかを追跡する。自分のマシンが遅れ始めたら、その数値が示しているのは自分のマシンのことだ。

### 実行のセットアップ

<EmbeddedTable
  table={{
    columns: [
      { key: "rule", width: 300, title: "ルール", dataType: "object" },
      { key: "why", width: 480, title: "重要な理由", dataType: "object" },
    ],
    data: [
      {
        rule: {
          title:
            "アプリケーションが実際に呼び出すメソッドをテストし、すべてのプロバイダーで同じペイロードを使う",
          tooltip: "",
          icon: "",
        },
        why: {
          title:
            "ベンチマークが比較できるのは送ったものだけだ。各メソッドは単独でフルレートで実行する。そうしないと、重いメソッドは安定したテールを集められない",
          tooltip: "",
          icon: "",
        },
        id: 0,
      },
      {
        rule: {
          title: "本番に近いRPSのレートを使う",
          tooltip: "",
          icon: "",
        },
        why: {
          title:
            "50 RPSでは同じに見えるプロバイダーも、300では差が開くことがある。帯域幅にも注意する。範囲の広い<code>eth_getLogs</code>は回線を飽和させ、性能劣化のように見えるからだ",
          tooltip: "",
          icon: "",
        },
        id: 1,
      },
      {
        rule: { title: "何を成功とみなすかを決める", tooltip: "", icon: "" },
        why: {
          title:
            "レイテンシーは成功したリクエストだけを数えるので、速く失敗しても評価されない。最終バイトまでの時間を測る。429は別枠で集計する",
          tooltip: "",
          icon: "",
        },
        id: 2,
      },
    ],
  }}
/>

### 実行する

<EmbeddedTable
  table={{
    columns: [
      { key: "rule", width: 300, title: "ルール", dataType: "object" },
      { key: "why", width: 480, title: "重要な理由", dataType: "object" },
    ],
    data: [
      {
        rule: {
          title: "すべてのプロバイダーを同じ条件でウォームアップする",
          tooltip: "",
          icon: "",
        },
        why: {
          title:
            "各メソッドの前に、すべてのプロバイダーに対してフルレートで10秒間送信し、その結果は捨てる。リクエスト数ではなく必ず時間で決める。500 RPSで10リクエストなら、ウォームアップは20msにしかならない",
          tooltip: "",
          icon: "",
        },
        id: 0,
      },
      {
        rule: {
          title: "スケジュールを守り、自分のマシンを監視する",
          tooltip: "",
          icon: "",
        },
        why: {
          title:
            "1,000サンプルで送信スキューのp99が5msを超えたら、その実行にフラグを立てる。その時点で測っているのは自分のマシンだ",
          tooltip: "",
          icon: "",
        },
        id: 1,
      },
      {
        rule: {
          title: "プロバイダーは一つずつテストする",
          tooltip: "",
          icon: "",
        },
        why: {
          title:
            "同時に実行すると帯域幅を奪い合い、それに勝ったほうが速く見えてしまう。それぞれに順番を与え、実行ごとに順序を入れ替える",
          tooltip: "",
          icon: "",
        },
        id: 2,
      },
    ],
  }}
/>

ブロックラグは例外だ。「どのプロバイダーがこのブロックを最初に通知したか」は、すべてのプロバイダーを同じ瞬間に監視して初めて意味を持つ。また、1ブロックにつき小さなメッセージが一つだけなので、帯域幅を奪い合うこともない。

### 結果を読む

<EmbeddedTable
  table={{
    columns: [
      { key: "rule", width: 300, title: "ルール", dataType: "object" },
      { key: "why", width: 480, title: "重要な理由", dataType: "object" },
    ],
    data: [
      {
        rule: {
          title:
            "同一のリクエストで、二つのプロバイダー間の差を測る。その差がゼロでもおかしくないなら、引き分けとする",
          tooltip: "",
          icon: "",
        },
        why: {
          title:
            "互いの信頼区間の内側にあるプロバイダーは、データ上では差がついていない。ペアのサンプルが100未満なら、判定自体をしない",
          tooltip: "",
          icon: "",
        },
        id: 0,
      },
      {
        rule: {
          title: "システムが動く場所から、2回実行する",
          tooltip: "",
          icon: "",
        },
        why: {
          title:
            "レイテンシーは、自分とプロバイダーの間のネットワーク経路に左右される。2回実行すれば、異なるネットワーク条件の下で性能がどう保たれるかがわかる",
          tooltip: "",
          icon: "",
        },
        id: 1,
      },
    ],
  }}
/>

## Alchemy rpcbenchとは何か?

Alchemy rpcbenchは、上記の方法論全体を、自分のマシンから自分のキーで実行する単一のバイナリだ。リクエストは設定ファイルに記載したエンドポイントにだけ送られ、生成されるHTMLレポートは直接あなたに届く。

私たちがこれを作ったのは、方法論を書き起こすのは簡単な半分にすぎないからだ。上記の各ルールは正しく実装するのに何日もかかり、しかもほとんどは間違えても目に見えない。測定ツールにとって最悪の組み合わせだ。

デフォルト設定は出発点にすぎない。`workload:`セクションで、自分のパラメーターとメソッドに置き換えられる:

<CodeSnippet
  language="yaml"
  code={`workload:
  - method: eth_call
    params:
      - to: "0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48"  # a contract on your quote path
        data: "0x18160ddd"                                 # and your calldata
      - "$anchor"                                          # the pinned block every provider is asked about`}
/>

レートの段階、実行時間、タイムアウト、ブロックラグの計測期間も同様に設定できる。また、プリフライトのパスが、負荷がマシンから出ていく前に、実行のコストをリクエスト数、時間、帯域幅で見積もる。そのコストはAlchemyのコンピュートユニットで示されるので、規模の目安として読むこと。

実行のたびに、JSONファイル、CSVの集計、自己完結型のHTMLダッシュボードが書き出される。裏付けのない数値は出さない。サンプルが少ない、プロバイダーがスロットリングされた、マシンが遅れた、といった場合はすべて冒頭でフラグが立つ。

このゲートを通過した実行からは、次の四つがこの順で得られる:

<EmbeddedTable
  table={{
    columns: [
      { key: "get", width: 240, title: "得られるもの", dataType: "object" },
      { key: "tells", width: 540, title: "わかること", dataType: "object" },
    ],
    data: [
      {
        get: { title: "有効性の判定", tooltip: "", icon: "" },
        tells: {
          title: "この実行が、そもそも引用に値するかどうか。何よりも先に読む",
          tooltip: "",
          icon: "",
        },
        id: 0,
      },
      {
        get: { title: "比較", tooltip: "", icon: "" },
        tells: {
          title:
            "ノイズに埋もれないほど大きな差だけ。区間が重なる場合は引き分けとして返される",
          tooltip: "",
          icon: "",
        },
        id: 1,
      },
      {
        get: { title: "メソッドごとのレイテンシー", tooltip: "", icon: "" },
        tells: {
          title:
            "各レート段階でのp50、p90、p95、p99と、それに並べた成功率、失敗率、429率",
          tooltip: "",
          icon: "",
        },
        id: 2,
      },
      {
        get: { title: "ブロックラグと整合性", tooltip: "", icon: "" },
        tells: {
          title:
            "各ブロックを誰が最初に通知したか、他のプロバイダーがどれだけ遅れたか、取りこぼしたブロック、各ヘッドのデータが提供可能だったか",
          tooltip: "",
          icon: "",
        },
        id: 3,
      },
    ],
  }}
/>

## この方法論からわからないこと

- あるリージョンの結果は、別のリージョンについて何も語らない。システムが別の場所で動いているなら、そこから実行すること。
- ブロックラグは、テストした中で最も速いプロバイダーに対する相対値であり、真のチェーン先端に対する値ではない。
- メソッドは一つずつ実行されるので、実行結果が本番トラフィックの構成を再現することはない。
- 1回の実行は一つのデータポイントにすぎない。チェーン全体の問題を含め、多くの要因が測定値に影響しうるので、性能について確かなシグナルを得るために複数回の実行を強く推奨する。
- Alchemy rpcbenchツールはEVMネットワーク専用で、1回の実行で対応するのは一つのネットワークだけだ。

## Alchemy rpcbenchを利用するには?

Alchemy rpcbenchはプライベートアルファ版だ。アクセスをリクエストするには[こちらのフォームに記入する](/rpcbench-access)こと。

すでに持っているツールで自作したいなら、上記の方法論がそのすべてだ。最終的に判断の根拠とする数値が、自分で出したものである限り、どちらでも私たちは歓迎する。

## よくある質問

### RPCプロバイダーはどう比較すべきか?

システムが動くリージョンから、システムが実際に呼び出すメソッドで、すべてのプロバイダーに同じワークロードを実行する。固定のスケジュールで送信し、プロバイダーは一つずつテストし、一つのブロックを固定して全員が同じ問いに答えるようにする。結果はメソッドごとに、すべてのレイテンシーの数値に失敗数とレート制限の回数を並べて読み、時間を変えてもう一度繰り返す。自分で構築したくなければ、Alchemy rpcbenchへのアクセスについて[お問い合わせ](/rpcbench-access)を。

### RPCのレイテンシー、ブロックラグ、データ整合性の違いは何か?

レイテンシーは、送ったリクエストにプロバイダーが応答するまでの時間だ。ブロックラグは、新しいブロックの存在を知らせるまでの時間だ。データ整合性は、そう知らせた瞬間に、そのブロックのログ、レシート、トランザクションを提供できるかどうかだ。プロバイダーは三つすべてに強いこともあれば、一つに強く別の一つで遅れていることもある。だからこそ、これらは別々の列に置くべきなのだ。

### プロバイダーが作ったベンチマークツールの結果は信頼できるのか?

できる。しかも私たちの言葉を鵜呑みにする必要はない。Alchemy rpcbenchには、通信先のプロバイダーによって分岐するコードパスが一つもないので、プロバイダー固有のタイムアウトやリトライを隠す余地はない。READMEにある監査用プロンプトを使って、任意のコーディングエージェントにクローンを調べさせれば、代わりに確認してくれる。ツールは自分のマシン上で自分のキーを使って動作し、結果が出力フォルダーの外に出ることはない。

### RPCプロバイダーは、単一の総合パフォーマンススコアで選ぶべきか?

いいえ。総合スコアは重み付けを勝手に決めてしまうが、正しい重み付けはアプリケーションによって異なる。履歴をバックフィルするインデクサーと、ブロックと競争するアービトラージボットが、プロバイダーに求めるものにはほとんど共通点がない。構築しているものに合った項目を読み、それをメソッドごとに読むこと。

### RPCベンチマークはどこから実行すべきか?

アプリケーションが動くリージョンからだ。RPCのレイテンシーは、クライアントとプロバイダーの間のネットワーク経路に大きく左右される。そのため、ノートPCや、デプロイしていないクラウドリージョンから実行したベンチマークは、本番トラフィックが決して通らない経路を測ることになる。

### RPCベンチマークの実行にはどれくらい時間がかかるか?

実行時間はテストの設定次第だが、デフォルト設定では約2時間かかる。テストの設定と開始は10分もかからない。Alchemy rpcbenchに同梱の設定では、Ethereum上で7つのメソッドと3つのレート段階にわたり、プロバイダーあたり28万リクエストを約48分で送信し、ブロックラグの計測期間がさらに1時間加わる。プロバイダーは順番に実行されるので、レイテンシーのフェーズはテストするプロバイダーの数に応じて長くなる。確かな結果にはサンプルが必要なので、午後いっぱいを見込んでおくこと。

### RPCプロバイダーをベンチマークするにはWebSocketエンドポイントが必要か?

レイテンシーには不要だ。ブロックラグとデータ整合性には必要だ。どちらも`eth_subscribe`と`newHeads`の購読に依存するからだ。また、ブロックラグは各ブロックを誰が最初に通知したかを測るので、少なくとも二つのプロバイダーが必要になる。

### どのRPCプロバイダーをテストできるか?

テスト対象のチェーンでEVMのJSON-RPCエンドポイントを持つプロバイダーなら、どれでもよい。URLとキーは自分で用意する。方法論にもツールにも、プロバイダーが誰かに依存する部分はない。

### Alchemyは自社のRPCベンチマークを公開しているか?

している。私たちの[ベンチマークページ](/benchmarks)では、継続的なプロバイダー比較を公開しており、今すぐ読める。Alchemy rpcbenchは、自分のアプリケーションのワークロードで、アプリケーションが動くリージョンから、自分自身のベンチマークを出すためのものだ。