Telemetry の取り込みとクエリのパフォーマンスのベンチマーク
有用なベンチマークは、単一の高速スクリーンショットではなく、公開された条件での再現可能な測定です。このガイドでは、パブリック ログ API およびクエリ API 用の制限されたクライアント側ハーネスを提供し、その数値が何を証明するのか、証明しないのかについて説明します。
Telemetry は、正確なスクリプト、環境、イベントの形状、行数、時間、結果、および制限が一緒に保持されるまで、このハーネスからのパフォーマンスの主張を公開しません。
実行する前に答えるべき質問
質問を 1 つ選択してください:
- このクライアントは既知の合成バッチを送信するのにどれくらい時間がかかりますか?
- リアルタイム データが有効になっている場合、クエリは送信されたばかりの実行をどれくらい早く読み取ることができますか?
- ペイロード幅によって、クライアントが観測する取り込み時間はどのように変化しますか?
- クエリ時間ウィンドウ、選択された列、およびグループ化カーディナリティは応答時間にどのように影響しますか?
これらすべてを 1 つの「速度」数値に混ぜ合わせないでください。クライアントのウォールクロック測定には、サービス時間に加えて、ネットワーク距離、TLS、ローカル スケジューリング、およびシリアル化が含まれます。
安全性と範囲
付属のハーネスは合成行を書き込みます。 telemetry_benchmark_events。次の場合を除き、実行を拒否します。
TELEMETRY_API_KEY実行時に設定されます。--confirm-write存在します。- 要求された行数は 1 ～ 10,000 です。
専用のテスト チームまたは API キーを使用します。スクリプトは行を削除しません。テーブルの通常の保持ポリシーを適用するか、承認されたデータ管理プロセスを通じて後でテスト データを削除します。
環境変数は、Web サイトとアプリケーションではオプションです。これは、人が意図的にベンチマーク スクリプトを実行する場合にのみ必要になります。
境界のあるハーネスを実行する
このリポジトリから:
TELEMETRY_API_KEY="YOUR_TEST_KEY" \
node scripts/benchmark-telemetry-api.mjs \
--confirm-write \
--rows 500 \
--batch-size 100
出力は、以下を含む 1 つの JSON ドキュメントです。
- 不透明な
run_id; - UTC の開始時刻と終了時刻。
- 要求された行とバッチサイズ。
- ペイロードの合計バイト数。
- クライアントが観測した取り込みウォールタイム。
- クライアントの壁時計秒あたりの計算行数。
- クライアントが観測したクエリウォールタイム。
- その実行のクエリ結果。
出力をにリダイレクトします agent_space/ 診断データをコミットせずにローカル実行を比較したい場合:
node scripts/benchmark-telemetry-api.mjs \
--confirm-write \
--rows 500 \
--batch-size 100 \
> agent_space/benchmark-500.json
スクリプトが送信するもの
すべての行は決定的な形状を使用します。
{
"run_id": "unique-per-run",
"sequence": 42,
"event_name": "benchmark_request_completed",
"route": "/synthetic/orders",
"region": "test-west",
"status_code": 200,
"latency_ms": 47,
"payload_size_bytes": 768,
"success": true
}
値は、決定論的な式を使用してシーケンスによって異なります。したがって、実行には成功した行と失敗した行に加えて、顧客のようなランダムなデータは含まれず、制限されたレイテンシー値が含まれます。
検証クエリは次のとおりです。
SELECT
COUNT(*) AS rows_observed,
SUM(CASE WHEN success THEN 1 ELSE 0 END) AS successful_rows,
AVG(latency_ms) AS average_synthetic_latency_ms,
MAX(sequence) AS maximum_sequence
FROM telemetry_benchmark_events
WHERE run_id = 'RUN_ID';
latency_ms は合成ペイロード フィールドです。これは、Telemetry サービスの遅延を表すものではありません。ハーネスによって測定されたクエリと取り込みのウォールタイムは別のフィールドです。
再現性記録
すべての結果でこのコンテキストを維持します。
| フィールド | なぜそれが重要なのか |
|---|---|
| スクリプトのコミット | 正確なジェネレーターとタイマーを識別します |
| UTC タイムスタンプ | アンカーサービスのバージョンと外部条件 |
| クライアントのリージョンとランタイム | ネットワークとローカルの違いについて説明します |
| API 原点 | 実稼働、ステージング、およびローカル テストを分離する |
| 行とバッチサイズ | リクエスト数とペイロードサイズを変更する |
| イベントスキーマ | シリアル化された幅とテーブルの形状に影響を与える |
| テーブルの状態と保持 | クエリスキャン作業に影響を与える可能性があります |
| SQL およびリアルタイム オプション | 測定されたクエリを定義します |
| ウォームアップポリシーと繰り返し | 冷酷な行動と差異を分離する |
| 中央値と末尾の値 | 有利なランを 1 つ選択することを避ける |
比較結果を得るには、A のすべてのトライアルを実行してから B のすべてのトライアルを実行するのではなく、候補を代替します。外部負荷は時間の経過とともにドリフトする可能性があります。
失敗を隠すことなく実験を改善する
小さなウォームアップを個別に実行し、ラベルを付けます。次に、中央値と高いパーセンタイルまたは完全な分布を報告するのに十分な繰り返しを収集します。タイムアウトを明示的に保ち、タイムアウトを削除するのではなく結果としてカウントします。
一度に 1 つの変数を変更します。
- 行数を修正し、バッチ サイズを変更します。
- バッチサイズを修正し、ペイロード幅を変更します。
- 取り込み条件を修正し、選択的クエリと広範なクエリを比較します。
- クエリを修正し、ウォーム間隔とアイドル間隔を比較します。
レート制限またはペイウォール応答が発生した場合は、HTTP ステータスを記録して停止します。クライアントの再試行時間をそのままの取り込みパフォーマンスとして解釈しないでください。
責任を持って主張できること
擁護できる発言は範囲が狭い:
このコミットは、記録された UTC 時間に指定されたクライアント環境から、開示されたバッチで開示された数の合成行を送信しました。測定されたクライアントのウォールタイム分布は、実行アーティファクトに添付されました。
これは、普遍的なスループットの保証、サーバー側の容量制限、競合他社との比較ではありません。運用ワークロードの結果には、代表的なスキーマ、同時実行性、保持、クエリ パターン、リージョン、および調整されたテスト環境が必要です。
使用する Telemetry コストとボリュームの管理 収集量を測定し、 イベント取り込みのトラブルシューティング ベンチマークによって拒否されたイベントまたは欠落したイベントが明らかになった場合。