Skip to main content
중요한 면책 조항: 프로덕션 데이터 센터 전용이 지연 시간 테스트는 프로덕션 데이터 센터 환경 전용으로 설계되었습니다. 이러한 테스트를 로컬 머신이나 소비자 인터넷 연결에서 실행하지 마십시오. 로컬 대역폭은 Solana 구독을 많이 처리할 수 없으며 현실 세계의 성능을 반영하지 않는 의미 없는 결과를 생성할 것입니다.
동일 위치 배치 요구 사항: LaserStream 엔드포인트 근처 배포의미 있는 지연 시간 측정을 위해 선택한 LaserStream 엔드포인트와 동일한 지역에 테스트 인프라를 반드시 공동 배치해야 합니다. 네트워크 거리가 측정의 대부분을 차지하므로 다른 대륙에서 테스트하면 LaserStream 성능이 아닌 네트워크 지연 시간이 표시됩니다.

분산 블록체인 시스템에서의 지연 시간 이해

블록체인 스트리밍 서비스를 사용할 때, 분산 시스템에는 보편적인 시계가 없기 때문에 지연 시간 측정이 복잡해집니다. 전통적인 시스템에서는 단일 서버까지의 왕복 시간을 측정할 수 있지만, 블록체인 네트워크는 여러 검증자가 관여하며, 각 검증자가 다른 시점에 동일한 트랜잭션을 수신 및 처리합니다. 기본적인 도전 과제: Solana와 같은 블록체인은 절대 시간이라는 개념이 없습니다. 각 검증자 노드는 전 세계적으로 동일한 트랜잭션을 다른 시점에 수신하게 되며, 확인은 클러스터의 일정 비율이 합의에 도달해야 합니다. 따라서 전통적인 의미에서 결정론적인 지연 시간 측정은 불가능합니다.

커밋 수준 및 지연 시간 우선순위

Solana는 각각 다른 지연 시간 특성을 가진 세 가지 커밋 수준을 제공합니다:
  • 처리됨(Processed): 가장 빠름, 단일 검증자 확인 (~400ms)
  • 확인됨(Confirmed): 중간, 슈퍼다수 확인 (~2-3초)
  • 완료됨(Finalized): 가장 느림, 네트워크 완전 최종화 (~15-30초)
지연 시간에 민감한 애플리케이션의 경우 처리된 커밋이 일반적으로 목표입니다. 이 가이드의 모든 테스트는 처리된 커밋 수준을 사용하며 대부분의 고주파수 사용 사례는 절대적 최종성보다 속도를 우선시합니다.

지연 시간 측정의 세 가지 접근 방식

1. 병렬 gRPC 스트림 비교

가장 신뢰할 수 있는 방법 - 동일한 데이터 소스에 대한 두 개의 독립된 스트림을 비교하여 동일한 이벤트를 먼저 수신하는지를 측정합니다. 장점:
  • 시계 동기화 문제 제거
  • 상대적 성능 비교 제공
  • 서비스 비교에 가장 정확

2. 로컬 타임스탬프 vs created_at 비교

중간 신뢰성 - 시스템이 메시지를 수신한 시점과 LaserStream 서비스에 의해 메시지에 내장된 타임스탬프 간의 차이를 측정합니다. 제한사항:
  • LaserStream이 내부적으로 메시지를 생성한 시점을 나타냅니다
  • LaserStream에 대한 업스트림 지연이 포착되지 않음
  • 진정한 종단 간 지연 시간에 대한 정확성이 방법 1보다 낮음

3. 블록 타임스탬프 분석 (권장하지 않음)

권장하지 않음 - Solana의 블록 타임스탬프와 로컬 수신 시간을 비교합니다. 중대한 제한사항:
  • 블록 타임스탬프는 초 단위의 정밀도만 가짐
  • Solana는 매 400ms마다 블록을 생성
  • 최소한의 유용한 정보 제공

설정 요구 사항

지역 동시 배치

의미 있는 지연 시간 측정을 위해 LaserStream 엔드포인트와 동일 데이터 센터 또는 지역에 테스트 인프라를 배포하십시오. 이용 가능한 LaserStream 지역:
  • ewr: 미국 뉴욕 (동부 해안) - https://laserstream-mainnet-ewr.helius-rpc.com
  • pitt: 미국 피츠버그 (중부) - https://laserstream-mainnet-pitt.helius-rpc.com
  • slc: 미국 솔트레이크시티 (서부 해안) - https://laserstream-mainnet-slc.helius-rpc.com
  • ams: 네덜란드 암스테르담, 유럽 - https://laserstream-mainnet-ams.helius-rpc.com
  • fra: 독일 프랑크푸르트, 유럽 - https://laserstream-mainnet-fra.helius-rpc.com
  • tyo: 일본 도쿄, 아시아 - https://laserstream-mainnet-tyo.helius-rpc.com
  • sgp: 싱가포르, 아시아 - https://laserstream-mainnet-sgp.helius-rpc.com
devnet 테스트를 위해, 다음을 사용하십시오: https://laserstream-devnet-ewr.helius-rpc.com 완벽한 설정 지침과 엔드포인트 선택 가이드라인은 LaserStream gRPC 문서를 참조하십시오.

Rust 환경 설정

모든 측정 스크립트는 Cargo와 함께 Rust를 사용합니다. 기본 설정:
자격 증명을 포함한 .env 파일을 만드십시오:
Helius 대시보드에서 Helius API 키를 가져오세요. 모든 플랜에서 LaserStream devnet을 사용할 수 있습니다. 메인넷 액세스는 비즈니스 또는 프로페셔널 플랜이 필요합니다.

방법 1: 병렬 스트림 비교

이 스크립트는 다른 gRPC 엔드포인트에 두 개의 독립된 연결을 설정하고 동일한 BlockMeta 메시지를 먼저 수신하는지를 측정합니다. 이 접근 방식은 상대적 타이밍을 사용하여 시계 동기화 문제를 제거합니다.
측정 대상: 두 스트리밍 서비스 간의 상대적 성능 차이를 측정합니다. 델타는 동일한 슬롯 정보를 먼저 전달하는 서비스를 보여줍니다. 주요 메트릭:
  • 양수 델타: 첫 번째 서비스 (YS)가 두 번째 서비스 (LS)보다 느림 - LaserStream이 더 빠름
  • 음수 델타: 첫 번째 서비스 (YS)가 두 번째 서비스 (LS)보다 빠름 - LaserStream이 느림
  • 평균/중앙값: 평균 성능 차이
  • P95: 95번째 백분위 지연 시간 차이
테스트 실행:
샘플 출력:
출력은 실시간 지연 시간 차이와 주기적인 통계를 보여줍니다. 양의 평균 델타는 두 번째 서비스 (LaserStream)가 일관되게 데이터를 더 빠르게 전달함을 나타냅니다.

방법 2: 생성된 타임스탬프 분석

이 접근 방식은 메시지에 포함된 created_at 타임스탬프와 수신 시 로컬 시스템 시간과 비교합니다.
중요한 제한사항: 이 방법은 LaserStream이 메시지를 생성한 시점부터 귀하가 수신한 시점까지만 측정합니다. 블록체인 이벤트와 LaserStream 처리 간의 업스트림 지연은 고려되지 않습니다. 테스트 실행:
샘플 출력:
이 방법은 LaserStream과 애플리케이션 간의 네트워크와 처리 지연 시간에 대한 통찰력을 제공하지만 포괄적인 분석을 위해 방법 1과 함께 사용해야 합니다.

지연 시간 테스트를 위한 모범 사례

주요 원칙

  • 동일 위치 배치: 네트워크 지연 시간을 최소화하기 위해 LaserStream 엔드포인트와 동일 지역에 테스트를 배포하십시오
  • 여러 방법 사용: 병렬 스트림 비교 방법(방법 1)을 기본 메트릭으로 사용하고 타임스탬프 분석으로 보완하십시오
  • 장기 모니터링: 다양한 네트워크 조건과 블록체인 혼잡을 포착하기 위해 테스트를 장기간 수행하십시오
  • 통계 분석: 평균뿐만 아니라 백분위수(P95, P99)에 집중하여 꼬리 지연 시간을 이해하십시오

결과 해석

  1. 기준 수립: 정상 상태에서 성능 기준을 수립하기 위해 최소 1시간 동안 테스트 실행
  2. 패턴 식별: 지연 시간 급증 패턴 조사 - 높은 블록체인 활동이나 네트워크 혼잡과 상관관계가 있는가?
  3. 백분위수 비교: 사용자 경험을 위해 P95 지연 시간이 평균 지연 시간보다 더 중요할 때가 많음
  4. 일관성 모니터링: 일관된 성능이 절대적인 최소 지연 시간보다 더 가치 있을 때가 많음
블록체인 지연 시간은 네트워크 합의 요구 사항 때문에 본질적으로 가변적입니다. 절대적인 숫자보다 상대적 성능 차이와 일관성에 집중하십시오.