Skip to main content
TUYÊN BỐ MIỄN TRỪ TRÁCH NHIỆM QUAN TRỌNG: Chỉ dành cho trung tâm dữ liệu productionCác bài kiểm thử độ trễ này chỉ được thiết kế cho môi trường trung tâm dữ liệu production. KHÔNG chạy các bài kiểm thử này trên máy cục bộ hoặc kết nối Internet dân dụng. Băng thông cục bộ không thể xử lý các subscription Solana nặng và sẽ cho ra kết quả vô nghĩa, không phản ánh hiệu năng thực tế.
YÊU CẦU ĐỒNG VỊ TRÍ: Triển khai gần endpoint LaserStream của bạnĐể có số liệu đo độ trễ có ý nghĩa, bạn phải đặt hạ tầng kiểm thử trong cùng khu vực với endpoint LaserStream đã chọn. Khoảng cách mạng sẽ chi phối kết quả đo — việc kiểm thử từ một châu lục khác sẽ phản ánh độ trễ mạng chứ không phải hiệu năng của LaserStream.

Tìm hiểu độ trễ trong các hệ thống blockchain phân tán

Khi làm việc với các dịch vụ truyền phát blockchain, việc đo độ trễ trở nên phức tạp vì các hệ thống phân tán không có đồng hồ chung. Không giống các hệ thống truyền thống, nơi bạn có thể đo thời gian khứ hồi đến một máy chủ duy nhất, mạng blockchain gồm nhiều trình xác thực, mỗi trình xác thực nhận và xử lý cùng một giao dịch tại các thời điểm khác nhau. Thách thức cơ bản: Các blockchain như Solana không có khái niệm thời gian tuyệt đối. Mỗi nút xác thực trên toàn cầu sẽ nhận cùng một giao dịch tại các thời điểm khác nhau và việc xác nhận phụ thuộc vào tỷ lệ phần trăm của cụm đạt được đồng thuận. Điều này khiến việc đo độ trễ theo cách tất định trở nên bất khả thi theo nghĩa truyền thống.

Các mức cam kết và mức độ ưu tiên về độ trễ

Solana cung cấp ba mức cam kết, mỗi mức có đặc điểm độ trễ khác nhau:
  • Đã xử lý: Nhanh nhất, xác nhận bởi một trình xác thực (~400ms)
  • Đã xác nhận: Trung bình, xác nhận bởi siêu đa số (~2-3 giây)
  • Đã hoàn tất: Chậm nhất, hoàn tất trên toàn mạng (~15-30 giây)
Đối với các ứng dụng nhạy cảm với độ trễ, mức cam kết đã xử lý thường là mục tiêu. Tất cả bài kiểm thử trong hướng dẫn này đều sử dụng mức cam kết đã xử lý vì hầu hết trường hợp sử dụng tần suất cao đều ưu tiên tốc độ hơn tính hoàn tất tuyệt đối.

Ba phương pháp đo độ trễ

1. So sánh các luồng gRPC song song

Phương pháp đáng tin cậy nhất — So sánh hai luồng độc lập đến cùng một nguồn dữ liệu, đo xem luồng nào nhận được các sự kiện giống nhau trước. Ưu điểm:
  • Loại bỏ các vấn đề đồng bộ hóa đồng hồ
  • Cung cấp phép so sánh hiệu năng tương đối
  • Chính xác nhất khi so sánh các dịch vụ

2. So sánh dấu thời gian cục bộ với created_at

Độ tin cậy trung bình — Đo chênh lệch giữa thời điểm hệ thống của bạn nhận được thông báo và dấu thời gian do dịch vụ LaserStream nhúng trong thông báo. Hạn chế:
  • Chỉ thể hiện thời điểm LaserStream tạo thông báo trong nội bộ
  • Không ghi nhận được độ trễ ở thượng nguồn trước khi đến LaserStream
  • Kém chính xác hơn Phương pháp 1 khi đo độ trễ đầu cuối thực sự

3. Phân tích dấu thời gian khối (không khuyến nghị)

Không khuyến nghị — So sánh thời gian nhận cục bộ với dấu thời gian khối của Solana. Hạn chế đáng kể:
  • Dấu thời gian khối chỉ có độ chi tiết đến giây
  • Solana tạo khối sau mỗi 400ms
  • Cung cấp rất ít thông tin hữu ích

Yêu cầu thiết lập

Đồng vị trí theo khu vực

Để có số liệu đo độ trễ có ý nghĩa, hãy triển khai hạ tầng kiểm thử trong cùng trung tâm dữ liệu hoặc khu vực với endpoint LaserStream của bạn. Các khu vực LaserStream hiện có:
  • ewr: New York, Hoa Kỳ (Bờ Đông) - https://laserstream-mainnet-ewr.helius-rpc.com
  • pitt: Pittsburgh, Hoa Kỳ (Miền Trung) - https://laserstream-mainnet-pitt.helius-rpc.com
  • slc: Salt Lake City, Hoa Kỳ (Bờ Tây) - https://laserstream-mainnet-slc.helius-rpc.com
  • ams: Amsterdam, Châu Âu - https://laserstream-mainnet-ams.helius-rpc.com
  • fra: Frankfurt, Châu Âu - https://laserstream-mainnet-fra.helius-rpc.com
  • tyo: Tokyo, Châu Á - https://laserstream-mainnet-tyo.helius-rpc.com
  • sgp: Singapore, Châu Á - https://laserstream-mainnet-sgp.helius-rpc.com
Để kiểm thử trên devnet, hãy sử dụng: https://laserstream-devnet-ewr.helius-rpc.com Xem tài liệu gRPC của LaserStream để biết hướng dẫn thiết lập đầy đủ và nguyên tắc chọn endpoint.

Thiết lập môi trường Rust

Tất cả script đo lường đều sử dụng Rust với Cargo. Thiết lập cơ bản:
Tạo tệp .env chứa thông tin xác thực của bạn:
Lấy khóa API Helius từ Bảng điều khiển Helius. LaserStream devnet có sẵn trong tất cả các gói. Quyền truy cập mainnet yêu cầu gói Business hoặc Professional.

Phương pháp 1: So sánh các luồng song song

Script này thiết lập hai kết nối độc lập đến các endpoint gRPC khác nhau và đo xem kết nối nào nhận được cùng một thông báo BlockMeta trước. Phương pháp này loại bỏ các vấn đề đồng bộ hóa đồng hồ bằng cách sử dụng thời gian tương đối.
Nội dung được đo: Chênh lệch hiệu năng tương đối giữa hai dịch vụ truyền phát. Giá trị delta cho biết dịch vụ nào phân phối cùng một thông tin slot trước. Các chỉ số chính:
  • Delta dương: Dịch vụ thứ nhất (YS) chậm hơn dịch vụ thứ hai (LS) — LaserStream nhanh hơn
  • Delta âm: Dịch vụ thứ nhất (YS) nhanh hơn dịch vụ thứ hai (LS) — LaserStream chậm hơn
  • Trung bình/Trung vị: Chênh lệch hiệu năng trung bình
  • P95: Chênh lệch độ trễ tại phân vị thứ 95
Chạy bài kiểm thử:
Đầu ra mẫu:
Đầu ra hiển thị chênh lệch độ trễ theo thời gian thực và số liệu thống kê định kỳ. Delta trung bình dương cho biết dịch vụ thứ hai (LaserStream) luôn phân phối dữ liệu nhanh hơn.

Phương pháp 2: Phân tích dấu thời gian tạo

Phương pháp này so sánh dấu thời gian created_at được nhúng trong thông báo với thời gian hệ thống cục bộ khi bạn nhận được thông báo.
Hạn chế quan trọng: Phương pháp này chỉ đo khoảng thời gian từ lúc LaserStream tạo thông báo đến lúc bạn nhận được thông báo. Phương pháp này không tính đến bất kỳ độ trễ thượng nguồn nào giữa sự kiện blockchain và quá trình xử lý của LaserStream. Chạy bài kiểm thử:
Đầu ra mẫu:
Phương pháp này cung cấp thông tin chuyên sâu về độ trễ mạng và độ trễ xử lý giữa LaserStream với ứng dụng của bạn, nhưng nên được sử dụng cùng Phương pháp 1 để có kết quả phân tích toàn diện.

Phương pháp hay nhất để kiểm thử độ trễ

Các nguyên tắc chính

  • Đồng vị trí: Triển khai các bài kiểm thử trong cùng khu vực với endpoint LaserStream để giảm thiểu độ trễ mạng
  • Nhiều phương pháp: Sử dụng phép so sánh các luồng song song (Phương pháp 1) làm chỉ số chính và bổ sung bằng phân tích dấu thời gian
  • Giám sát dài hạn: Chạy kiểm thử trong thời gian dài để ghi nhận các điều kiện mạng và mức độ tắc nghẽn blockchain khác nhau
  • Phân tích thống kê: Tập trung vào các phân vị (P95, P99) thay vì chỉ dùng giá trị trung bình để hiểu độ trễ đuôi

Diễn giải kết quả

  1. Thiết lập đường cơ sở: Chạy kiểm thử trong ít nhất 1 giờ để thiết lập hiệu năng cơ sở trong điều kiện bình thường
  2. Xác định quy luật: Tìm quy luật trong các đợt tăng đột biến về độ trễ — chúng có tương quan với hoạt động blockchain cao hoặc tình trạng tắc nghẽn mạng không?
  3. So sánh các phân vị: Độ trễ P95 thường quan trọng hơn độ trễ trung bình đối với trải nghiệm người dùng
  4. Theo dõi tính nhất quán: Hiệu năng ổn định thường có giá trị hơn độ trễ tối thiểu tuyệt đối
Hãy nhớ rằng độ trễ blockchain vốn biến thiên do các yêu cầu về đồng thuận mạng. Hãy tập trung vào chênh lệch hiệu năng tương đối và tính nhất quán thay vì các con số tuyệt đối.