メインコンテンツへスキップ
重大な免責事項: 本番データセンターのみこれらの待ち時間テストは、本番データセンター環境専用に設計されています。これらのテストをローカルマシンやコンシューマーインターネット接続で実行しないでください。ローカル帯域幅はソラナサブスクリプションを処理できず、実際のパフォーマンスを反映しない無意味な結果を生み出します。
同ロケーション要件: お使いのLaserStreamエンドポイント近くにデプロイする有意義な待ち時間の測定を行うには、選択したLaserStreamエンドポイントと同じ地域にテストインフラを配置する必要があります。ネットワーク距離が測定を支配するため、異なる大陸からテストすると、LaserStreamのパフォーマンスではなくネットワークの待ち時間が表示されます。

分散型ブロックチェーンシステムでの待ち時間の理解

ブロックチェーンストリーミングサービスを使用する場合、分散システムには普遍的な時計がないため、待ち時間の測定は複雑になります。単一サーバーへの往復時間を測定できる従来のシステムとは異なり、ブロックチェーンネットワークには複数のバリデータが関与しており、各バリデータは同じトランザクションを異なる時間に受信して処理します。 基本的な課題: Solanaのようなブロックチェーンには絶対時間の概念がありません。各バリデータノードは世界中で同じトランザクションを異なる時間に受信し、確認はクラスターのパーセンテージが合意に達することに依存しています。これにより、従来の意味での決定的な待ち時間測定が不可能になります。

コミットメントレベルと待ち時間の優先順位

Solanaは3つのコミットメントレベルを提供し、それぞれに異なる待ち時間特性があります:
  • Processed: 最速、単一バリデータの確認(約400ms)
  • Confirmed: 中程度、スーパーマジョリティーの確認(約2〜3秒)
  • Finalized: 最も遅い、ネットワーク全体の最終化(約15〜30秒)
待ち時間が重要なアプリケーションでは、通常、プロセス済みコミットメントが目標となります。このガイドのすべてのテストは、ほとんどの高頻度使用のケースが絶対的なファイナリティよりもスピードを優先するため、プロセス済みコミットメントレベルを使用しています。

待ち時間を測定する3つのアプローチ

1. 並列gRPCストリームの比較

最も信頼性の高い方法 - 同じデータソースに対して2つの独立したストリームを比較し、同一のイベントをどちらが先に受信するかを測定します。 利点:
  • 時計同期の問題を排除
  • 相対的なパフォーマンス比較を提供
  • サービス比較に最も正確

2. ローカルタイムスタンプとcreated_atの比較

中程度の信頼性 - LaserStreamサービスによってメッセージに埋め込まれたタイムスタンプと、システムがメッセージを受信した時刻の差を測定します。 制限事項:
  • LaserStreamが内部でメッセージを作成した時点のみを表す
  • LaserStreamへの上流遅延はキャプチャされない
  • 真のエンドツーエンドの待ち時間に対してMethod 1よりも精度が低い

3. ブロックタイムスタンプ分析(非推奨)

非推奨 - Solanaのブロックタイムスタンプとローカルの受信時刻を比較します。 重要な制限:
  • ブロックタイムスタンプは秒単位の粒度しかない
  • Solanaは400msごとにブロックを生成
  • 有用な情報はほとんど提供しない

セットアップ要件

地域的な同ロケーション

有意義な待ち時間測定を行うには、テストインフラをLaserStreamエンドポイントと同じデータセンターまたは地域にデプロイします。 利用可能なLaserStream地域:
  • ewr: ニューヨーク, US (東海岸)
  • pitt: ピッツバーグ, US (中部)
  • slc: ソルトレイクシティ, US (西海岸)
  • ams: アムステルダム, ヨーロッパ
  • fra: フランクフルト, ヨーロッパ
  • tyo: 東京, アジア
  • sgp: シンガポール, アジア
devnetテストには、次を使用します: 完全なセットアップ手順とエンドポイント選択ガイドラインについては、LaserStream gRPCドキュメントを参照してください。

Rust環境のセットアップ

すべての測定スクリプトはRustとCargoを使用します。基本設定:
認証情報を含むファイルを作成します:
Helius APIキーはHelius Dashboardから入手できます。LaserStream devnetはすべてのプランで利用可能です。メインネットアクセスにはビジネスまたはプロフェッショナルプランが必要です。

方法1: 並列ストリーム比較

このスクリプトは、異なるgRPCエンドポイントへの2つの独立した接続を確立し、同じメッセージをどちらが先に受信するかを測定します。このアプローチは、相対的なタイミングを使用して時計同期の問題を排除します。
これが測定するもの: 2つのストリーミングサービス間の相対的なパフォーマンスの違い。デルタは、どのサービスが同じスロット情報を最初に提供するかを示します。 主要な指標:
  • 正のデルタ: 最初のサービス(YS)が2番目のサービス(LS)より遅い - LaserStreamの方が速い
  • 負のデルタ: 最初のサービス(YS)が2番目のサービス(LS)より速い - LaserStreamの方が遅い
  • 平均/中央値: 平均パフォーマンスの違い
  • P95: 95パーセンタイルの待ち時間差
テストの実行:
サンプル出力:
出力はリアルタイムの待ち時間差と定期的な統計を表示します。正の平均デルタは、2番目のサービス(LaserStream)が一貫してデータをより速く提供していることを示します。

方法2: 作成タイムスタンプ分析

このアプローチは、メッセージに埋め込まれたタイムスタンプをローカルシステム時間と比較します。
重要な制限: この方法は、LaserStreamがメッセージを作成したときから受信したときまでの時間のみを測定します。ブロックチェーンイベントとLaserStream処理の間の上流遅延は考慮されません。 テストの実行:
サンプル出力:
この方法は、LaserStreamとアプリケーション間のネットワークおよび処理の待ち時間に関する洞察を提供しますが、Method 1と組み合わせて使用することで包括的な分析が可能です。

待ち時間テストのベストプラクティス

重要な原則

  • 同ロケーション: テストをLaserStreamエンドポイントと同じ地域にデプロイしてネットワーク待ち時間を最小化
  • 複数の方法: 並列ストリーム比較(方法1)を主要な指標として使用し、タイムスタンプ分析で補完
  • 長期監視: テストを長期間にわたって実行し、異なるネットワーク条件やブロックチェーンの混雑を把握
  • 統計分析: 平均だけでなくパーセンタイル(P95, P99)に焦点を当ててテール待ち時間を把握

結果の解釈

  1. ベースラインの確立: 通常の条件下でのベースラインパフォーマンスを確立するために最低1時間のテストを実施
  2. パターンの特定: 待ち時間のスパイクのパターンを探し、ブロックチェーンの高いアクティビティやネットワークの混雑と関連があるか確認
  3. パーセンタイルの比較: ユーザーエクスペリエンスにおいては平均待ち時間よりもP95待ち時間が重要であることが多い
  4. 一貫性の監視: 絶対最小待ち時間よりも一貫したパフォーマンスがより価値があることが多い
ブロックチェーンの待ち時間は、ネットワークの合意要件のため本質的に変動します。絶対値よりも相対的なパフォーマンスの違いと一貫性に焦点を当てましょう。