Skip to main content
AVERTISSEMENT CRITIQUE : Centre de données de production uniquementCes tests de latence sont conçus uniquement pour les environnements de centre de données de production. NE PAS effectuer ces tests sur des machines locales ou des connexions internet grand public. La bande passante locale ne peut pas gérer les abonnements lourds de Solana et produira des résultats sans signification qui ne reflètent pas les performances réelles.
EXIGENCE DE CO-LOCATION : Déployez près de votre point de terminaison LaserStreamPour des mesures de latence significatives, vous devez co-localiser votre infrastructure de test dans la même région que le point de terminaison LaserStream choisi. La distance réseau dominera vos mesures - tester depuis un autre continent montrera la latence du réseau, pas la performance de LaserStream.

Comprendre la latence dans les systèmes blockchain distribués

Lors de la manipulation de services de streaming blockchain, la mesure de la latence devient complexe car les systèmes distribués n’ont pas d’horloge universelle. Contrairement aux systèmes traditionnels où vous pouvez mesurer le temps d’aller-retour vers un seul serveur, les réseaux blockchain impliquent plusieurs validateurs, chacun recevant et traitant la même transaction à des moments différents. Le défi fondamental : Les blockchains comme Solana n’ont pas de concept de temps absolu. Chaque nœud valideur recevra globalement la même transaction à des moments différents, et la confirmation dépend d’un pourcentage du cluster atteignant un consensus. Cela rend la mesure déterministe de la latence impossible au sens traditionnel.

Niveaux d’engagement et priorités de latence

Solana offre trois niveaux d’engagement, chacun avec des caractéristiques de latence différentes :
  • Traité : Le plus rapide, confirmation d’un seul validateur (~400ms)
  • Confirmé : Moyen, confirmation de supermajorité (~2-3 secondes)
  • Finalisé : Le plus lent, finalisation complète du réseau (~15-30 secondes)
Pour les applications sensibles à la latence, l’engagement traité est généralement l’objectif. Tous les tests de ce guide utilisent le niveau d’engagement traité puisque la plupart des cas d’utilisation à haute fréquence privilégient la vitesse sur la finalité absolue.

Trois approches pour mesurer la latence

1. Comparer les flux gRPC parallèles

Méthode la plus fiable - Compare deux flux indépendants vers la même source de données, mesurant lequel reçoit d’abord des événements identiques. Avantages :
  • Élimine les problèmes de synchronisation d’horloge
  • Fournit une comparaison relative des performances
  • Le plus précis pour comparer les services

2. Comparaison de l’horodatage local vs created_at

Fiabilité modérée - Mesure la différence entre le moment où votre système reçoit un message et l’horodatage intégré dans le message par le service LaserStream. Limitations :
  • Représente seulement le moment où LaserStream a créé le message en interne
  • Les retards en amont vers LaserStream ne seront pas capturés
  • Moins précis que la Méthode 1 pour une latence de bout en bout réelle

3. Analyse de l’horodatage des blocs (non recommandé)

Non recommandé - Compare le temps de réception local contre l’horodatage du bloc de Solana. Limitations importantes :
  • Les horodatages des blocs n’ont qu’une granularité au niveau de la seconde
  • Solana produit des blocs toutes les 400ms
  • Fournit peu d’informations utiles

Exigences de configuration

Co-location régionale

Pour des mesures de latence significatives, déployez votre infrastructure de test dans le même centre de données ou région que votre point de terminaison LaserStream. Régions LaserStream disponibles :
  • ewr : New York, US (côte Est) - https://laserstream-mainnet-ewr.helius-rpc.com
  • pitt : Pittsburgh, US (central) - https://laserstream-mainnet-pitt.helius-rpc.com
  • slc : Salt Lake City, US (côte Ouest) - https://laserstream-mainnet-slc.helius-rpc.com
  • ams : Amsterdam, Europe - https://laserstream-mainnet-ams.helius-rpc.com
  • fra : Francfort, Europe - https://laserstream-mainnet-fra.helius-rpc.com
  • tyo : Tokyo, Asie - https://laserstream-mainnet-tyo.helius-rpc.com
  • sgp : Singapour, Asie - https://laserstream-mainnet-sgp.helius-rpc.com
Pour les tests sur devnet, utilisez : https://laserstream-devnet-ewr.helius-rpc.com Consultez la documentation gRPC de LaserStream pour des instructions complètes de configuration et des directives de sélection de point de terminaison.

Configuration de l’environnement Rust

Tous les scripts de mesure utilisent Rust avec Cargo. Configuration de base :
Créez un fichier .env avec vos identifiants :
Obtenez votre clé API Helius depuis le Tableau de bord Helius. LaserStream devnet est disponible sur tous les plans. L’accès au réseau principal nécessite un plan Business ou Professional.

Méthode 1 : Comparaison des flux parallèles

Ce script établit deux connexions indépendantes à différents points de terminaison gRPC et mesure lequel reçoit d’abord les mêmes messages BlockMeta. Cette approche élimine les problèmes de synchronisation d’horloge en utilisant le timing relatif.
Ce que cela mesure : La différence de performance relative entre deux services de streaming. Le delta montre quel service fournit en premier les mêmes informations de slot. Principales métriques :
  • Delta positif : Premier service (YS) plus lent que le deuxième service (LS) - LaserStream est plus rapide
  • Delta négatif : Premier service (YS) plus rapide que le deuxième service (LS) - LaserStream est plus lent
  • Moyenne/Médiane : Différence de performance moyenne
  • P95 : Différence de latence au 95e percentile
Exécution du test :
Exemple de sortie :
La sortie montre les différences de latence en temps réel et les statistiques périodiques. Un delta moyen positif indique que le deuxième service (LaserStream) fournit constamment les données plus rapidement.

Méthode 2 : Analyse des horodatages créés

Cette approche compare l’horodatage created_at intégré dans les messages par rapport à votre heure système locale lors de leur réception.
Limitation importante : Cette méthode ne mesure que depuis le moment où LaserStream a créé le message jusqu’à ce que vous l’ayez reçu. Elle ne tient pas compte des retards en amont entre l’événement blockchain et le traitement par LaserStream. Exécution du test :
Exemple de sortie :
Cette méthode fournit des informations sur la latence du réseau et de traitement entre LaserStream et votre application, mais devrait être utilisée en conjonction avec la Méthode 1 pour une analyse complète.

Meilleures pratiques pour le test de latence

Principes clés

  • Co-location : Déployez les tests dans la même région que votre point de terminaison LaserStream pour minimiser la latence réseau
  • Méthodes multiples : Utilisez la comparaison de flux parallèles (Méthode 1) comme métrique principale, complétée par l’analyse des horodatages
  • Surveillance à long terme : Effectuez des tests sur de longues périodes pour capturer différentes conditions de réseau et congestions blockchain
  • Analyse statistique : Concentrez-vous sur les percentiles (P95, P99) plutôt que juste les moyennes pour comprendre la latence de la traîne

Interprétation des résultats

  1. Établir une base de référence : Réalisez des tests pendant au moins 1 heure pour établir les performances de base dans des conditions normales
  2. Identifier les motifs : Recherchez des motifs dans les pics de latence - correspondent-ils à une activité blockchain élevée ou à une congestion réseau ?
  3. Comparer les percentiles : La latence P95 est souvent plus importante que la latence moyenne pour l’expérience utilisateur
  4. Surveiller la cohérence : Des performances cohérentes sont souvent plus précieuses qu’une latence minimale absolue
Rappelez-vous que la latence blockchain est intrinsèquement variable en raison des exigences de consensus du réseau. Concentrez-vous sur les différences de performance relative et la cohérence plutôt que sur les chiffres absolus.