벤치마크 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 서비스 대기 시간을 나타내지 않습니다. 하네스에 의해 측정된 쿼리 및 수집 벽 시간은 별도의 필드입니다.

재현성 기록

모든 결과에 대해 다음 컨텍스트를 유지하세요.

비교 결과를 얻으려면 A에 대한 모든 시도를 실행한 다음 B에 대한 모든 시도를 실행하는 대신 후보를 대체하십시오. 외부 로드는 시간이 지남에 따라 표류할 수 있습니다.

실패를 숨기지 않고 실험을 개선하세요

작은 워밍업을 별도로 실행하고 라벨을 붙입니다. 그런 다음 중앙값과 높은 백분위수 또는 전체 분포를 보고하기에 충분한 반복을 수집합니다. 시간 초과를 명시적으로 유지하고 시간 초과를 삭제하는 대신 결과로 계산합니다.

한 번에 하나의 변수를 변경하십시오.

1. 행 수를 수정하고 배치 크기를 변경합니다.
2. 배치 크기를 수정하고 페이로드 너비를 변경합니다.
3. 수집 조건을 수정하고 선택적 쿼리와 광범위한 쿼리를 비교합니다.
4. 쿼리를 수정하고 웜 간격과 유휴 간격을 비교합니다.

속도 제한이나 페이월 응답이 발생하면 HTTP 상태를 기록하고 중지합니다. 클라이언트 재시도 시간을 원시 수집 성능으로 해석하지 마세요.

책임감 있게 주장할 수 있는 것

방어할 수 있는 진술은 좁습니다.

기록된 UTC 시간에 명명된 클라이언트 환경에서 이 커밋은 공개된 배치의 공개된 수의 합성 행을 제출했습니다. 측정된 클라이언트 벽 시간 분포가 실행 아티팩트에 첨부되었습니다.

이는 보편적인 처리량 보장, 서버 측 용량 제한 또는 경쟁업체 비교가 아닙니다. 프로덕션 워크로드 결과에는 대표적인 스키마, 동시성, 보존, 쿼리 패턴, 지역 및 조정된 테스트 환경이 필요합니다.

벤치마크에서 거부되거나 누락된 이벤트가 노출되면 Telemetry 비용 및 볼륨 관리를 사용하여 수집 볼륨을 측정하고 이벤트 수집 문제 해결을 사용하세요.