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 giá trị cam kết. Trong Alpenglow,confirmed và finalized mô tả cùng một trạng thái vĩnh viễn:
- Đã xử lý: Việc thực thi được trình xác thực đang kết nối ghi nhận; có độ trễ thấp nhất nhưng có thể bị hoàn tác
- Đã xác nhận: Bí danh tương thích cho
finalized; dự kiến bị loại bỏ trong một bản phát hành sau - Đã hoàn tất: Cam kết sổ cái vĩnh viễn, thường đạt được khoảng 150 ms sau khi đề xuất khố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. Các hạn chế đáng kể:- Dấu thời gian của khối chỉ có độ chi tiết đến cấp giây
- Solana tạo khối sau mỗi 200 ms
- 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
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:.env chứa thông tin xác thực của bạn:
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áoBlockMeta 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.
- 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
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 giancreated_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.
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ả
- 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
- 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?
- 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
- 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