Telemetry 資料攝取與查詢效能基準測試
有用的基準是在公開條件下進行的可重複測量，而不是單個快速螢幕截圖。本指南為公共日誌和查詢 API 提供了有界客戶端工具，並解釋了其數字可以證明什麼和不能證明什麼。
在準確的指令碼、環境、事件形狀、行計數、時間、結果和限制保留在一起之前，Telemetry 不會發布此工具的效能宣告。
跑步前要回答的問題
選擇一個問題：
- 該客戶需要多長時間才能提交已知的合成批次？
- 在啟用即時資料的情況下，查詢讀取剛剛提交的執行的速度有多快？
- 有效負載寬度如何改變客戶端觀察到的攝取時間？
- 查詢時間視窗、所選列和分組基數如何影響回應時間？
不要將所有這些混合到一個“速度”數字中。除了服務時間之外，客戶端掛鐘測量還包括網路距離、TLS、本地排程和序列化。
安全性和範圍
隨附的線束將合成行寫入 telemetry_benchmark_events。它拒絕執行，除非：
TELEMETRY_API_KEY在執行時被設定；--confirm-write存在；- 請求的行數在 1 到 10,000 之間。
使用專門的測試團隊或API金鑰。該指令碼不會刪除行。應用資料表的正常保留策略或稍後透過批准的資料管理流程刪除測試資料。
環境變數對於網站和應用程式是可選的。僅當有人有意執行基準測試指令碼時才需要它。
執行有界線束
從這個儲存庫：
TELEMETRY_API_KEY="YOUR_TEST_KEY" \
node scripts/benchmark-telemetry-api.mjs \
--confirm-write \
--rows 500 \
--batch-size 100
輸出是一個 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 和即時選項 | 定義測量的查詢 |
| 熱身策略和重複 | 區分冷行為和方差 |
| 中值和尾值 | 避免選擇有利的執行 |
為了比較結果，請替換候選者，而不是執行 A 的所有試驗，然後執行 B 的所有試驗。外部負載可能會隨著時間的推移而漂移。
改進實驗而不隱藏失敗
單獨執行一個小的熱身並標記它。然後收集足夠的重複來報告中位數加上高百分位或完整分佈。保持超時明確並將超時計為結果而不是刪除它們。
一次更改一個變數：
- 修復行數並改變批次大小；
- 修復批次大小並改變有效負載寬度；
- 修復攝取條件並比較選擇性查詢與廣泛查詢；
- 修復查詢並比較熱間隔與空閒間隔。
如果發生速率限制或付費專區回應，請記錄 HTTP 狀態並停止。不要將客戶端重試時間解釋為原始攝取效能。
您可以負責任地主張什麼
一個可以辯護的說法是狹隘的：
在記錄的 UTC 時間的指定客戶端環境中，此提交按公開批次提交了公開數量的合成行。測量的客戶端牆時間分佈附加到執行工件。
這不是通用吞吐量保證、伺服器端容量限制或競爭對手比較。生產工作負載結果需要具有代表性的模式、併發性、保留性、查詢模式、區域和協調的測試環境。
使用 遙測成本與資料量管理 測量收集量，並在基準暴露拒絕或丟失事件時使用 事件攝取故障排除。