Zum Hauptinhalt springen
KRITISCHER HINWEIS: Nur für ProduktionsrechenzentrenDiese Latenztests sind ausschließlich für Produktionsrechenzentren vorgesehen. Führe diese Tests NICHT auf lokalen Rechnern oder über Internetverbindungen für Privatkunden aus. Die lokale Bandbreite reicht für umfangreiche Solana-Subscriptions nicht aus. Dadurch entstehen bedeutungslose Ergebnisse, die nicht die reale Performance widerspiegeln.
ANFORDERUNG AN DEN STANDORT: Stelle deine Infrastruktur in der Nähe deines LaserStream endpoint bereitFür aussagekräftige Latenzmessungen musst du deine Testinfrastruktur in derselben Region wie deinen gewählten LaserStream endpoint bereitstellen. Die Netzwerkentfernung dominiert deine Messungen. Wenn du von einem anderen Kontinent aus testest, misst du die Netzwerklatenz und nicht die Performance von LaserStream.

Latenz in verteilten Blockchain-Systemen verstehen

Bei Blockchain-Streamingdiensten ist die Latenzmessung komplex, da verteilte Systeme keine universelle Uhr haben. In herkömmlichen Systemen kannst du die Round-Trip-Zeit zu einem einzelnen Server messen. Blockchain-Netzwerke umfassen dagegen mehrere Validatoren, die dieselbe Transaktion zu unterschiedlichen Zeitpunkten empfangen und verarbeiten. Die grundlegende Herausforderung: Blockchains wie Solana kennen keine absolute Zeit. Jeder weltweit verteilte Validator-node empfängt dieselbe Transaktion zu einem anderen Zeitpunkt. Die Bestätigung hängt davon ab, dass ein bestimmter Anteil des cluster einen Konsens erreicht. Daher ist eine deterministische Latenzmessung im herkömmlichen Sinn unmöglich.

Commitment-Stufen und Latenzprioritäten

Solana bietet drei commitment-Stufen mit jeweils unterschiedlichen Latenzeigenschaften:
  • Processed: Am schnellsten, Bestätigung durch einen einzelnen Validator (~400 ms)
  • Confirmed: Mittel, Bestätigung durch eine Supermehrheit (~2–3 Sekunden)
  • Finalized: Am langsamsten, vollständige Finalisierung durch das Netzwerk (~15–30 Sekunden)
Für latenzkritische Anwendungen ist processed commitment normalerweise das Ziel. Alle Tests in diesem Leitfaden verwenden die Stufe processed commitment, da bei den meisten Hochfrequenz-Anwendungsfällen Geschwindigkeit wichtiger ist als absolute Finalität.

Drei Ansätze zur Latenzmessung

1. Parallele gRPC streams vergleichen

Zuverlässigste Methode – Vergleicht zwei unabhängige streams mit derselben Datenquelle und misst, welcher identische Ereignisse zuerst empfängt. Vorteile:
  • Vermeidet Probleme bei der Uhrensynchronisierung
  • Ermöglicht einen relativen Performance-Vergleich
  • Liefert die genauesten Ergebnisse beim Vergleich von Diensten

2. Lokalen Zeitstempel mit created_at vergleichen

Mittlere Zuverlässigkeit – Misst die Differenz zwischen dem Empfang einer Nachricht durch dein System und dem vom LaserStream-Dienst in die Nachricht eingebetteten Zeitstempel. Einschränkungen:
  • Zeigt nur, wann LaserStream die Nachricht intern erstellt hat
  • Vorgelagerte Verzögerungen bis zu LaserStream werden nicht erfasst
  • Für die tatsächliche Ende-zu-Ende-Latenz weniger genau als Methode 1

3. Block-Zeitstempel analysieren (nicht empfohlen)

Nicht empfohlen – Vergleicht die lokale Empfangszeit mit dem Block-Zeitstempel von Solana. Erhebliche Einschränkungen:
  • Block-Zeitstempel haben nur eine sekundengenaue Auflösung
  • Solana erzeugt alle 400 ms einen Block
  • Liefert kaum nützliche Informationen

Voraussetzungen für die Einrichtung

Regionale Nähe

Stelle deine Testinfrastruktur für aussagekräftige Latenzmessungen im selben Rechenzentrum oder in derselben Region wie deinen LaserStream endpoint bereit. Verfügbare LaserStream-Regionen:
  • ewr: New York, USA (Ostküste) - https://laserstream-mainnet-ewr.helius-rpc.com
  • pitt: Pittsburgh, USA (Zentralregion) - https://laserstream-mainnet-pitt.helius-rpc.com
  • slc: Salt Lake City, USA (Westküste) - https://laserstream-mainnet-slc.helius-rpc.com
  • ams: Amsterdam, Europa - https://laserstream-mainnet-ams.helius-rpc.com
  • fra: Frankfurt, Europa - https://laserstream-mainnet-fra.helius-rpc.com
  • tyo: Tokio, Asien - https://laserstream-mainnet-tyo.helius-rpc.com
  • sgp: Singapur, Asien - https://laserstream-mainnet-sgp.helius-rpc.com
Verwende für Tests im Devnet: https://laserstream-devnet-ewr.helius-rpc.com Vollständige Einrichtungsanweisungen und Hinweise zur Auswahl des endpoint findest du in der LaserStream-gRPC-Dokumentation.

Rust-Umgebung einrichten

Alle Messskripte verwenden Rust mit Cargo. Grundlegende Einrichtung:
Erstelle eine .env-Datei mit deinen Zugangsdaten:
Rufe deinen Helius API key im Helius Dashboard ab. LaserStream Devnet ist in allen Tarifen verfügbar. Für den Mainnet-Zugriff benötigst du einen Business- oder Professional-Tarif.

Methode 1: Parallele streams vergleichen

Dieses Skript stellt zwei unabhängige Verbindungen zu verschiedenen gRPC endpoints her und misst, welche Verbindung dieselben BlockMeta-Nachrichten zuerst empfängt. Dieser Ansatz vermeidet Probleme bei der Uhrensynchronisierung, indem er relative Zeitmessungen verwendet.
Was damit gemessen wird: Der relative Performance-Unterschied zwischen zwei Streamingdiensten. Das Delta zeigt, welcher Dienst dieselben slot-Informationen zuerst liefert. Wichtige Metriken:
  • Positives Delta: Der erste Dienst (YS) ist langsamer als der zweite Dienst (LS) – LaserStream ist schneller
  • Negatives Delta: Der erste Dienst (YS) ist schneller als der zweite Dienst (LS) – LaserStream ist langsamer
  • Mittelwert/Median: Durchschnittlicher Performance-Unterschied
  • P95: Latenzdifferenz im 95. Perzentil
Test ausführen:
Beispielausgabe:
Die Ausgabe zeigt Latenzdifferenzen in Echtzeit und regelmäßige Statistiken. Ein positives mittleres Delta bedeutet, dass der zweite Dienst (LaserStream) die Daten durchgehend schneller liefert.

Methode 2: Erstellungszeitstempel analysieren

Dieser Ansatz vergleicht den in Nachrichten eingebetteten created_at-Zeitstempel mit der lokalen Systemzeit beim Empfang.
Wichtige Einschränkung: Diese Methode misst nur den Zeitraum zwischen der Erstellung der Nachricht durch LaserStream und ihrem Empfang durch dich. Vorgelagerte Verzögerungen zwischen dem Blockchain-Ereignis und der Verarbeitung durch LaserStream werden nicht berücksichtigt. Test ausführen:
Beispielausgabe:
Diese Methode liefert Einblicke in die Netzwerk- und Verarbeitungslatenz zwischen LaserStream und deiner Anwendung. Verwende sie für eine umfassende Analyse jedoch zusammen mit Methode 1.

Best Practices für Latenztests

Grundprinzipien

  • Regionale Nähe: Stelle Tests in derselben Region wie deinen LaserStream endpoint bereit, um die Netzwerklatenz zu minimieren
  • Mehrere Methoden: Verwende den Vergleich paralleler streams (Methode 1) als primäre Metrik und ergänze ihn durch eine Zeitstempelanalyse
  • Langfristige Überwachung: Führe Tests über längere Zeiträume aus, um unterschiedliche Netzwerkbedingungen und eine hohe Blockchain-Auslastung zu erfassen
  • Statistische Analyse: Konzentriere dich auf Perzentile (P95, P99) statt nur auf Durchschnittswerte, um die Tail-Latenz zu verstehen

Ergebnisse interpretieren

  1. Baseline festlegen: Führe die Tests mindestens eine Stunde lang aus, um die normale Performance als Baseline zu bestimmen
  2. Muster erkennen: Suche nach Mustern bei Latenzspitzen. Korrelieren sie mit hoher Blockchain-Aktivität oder Netzwerküberlastung?
  3. Perzentile vergleichen: Für die Benutzererfahrung ist die P95-Latenz oft wichtiger als die durchschnittliche Latenz
  4. Konsistenz überwachen: Eine konsistente Performance ist oft wertvoller als die absolut niedrigste Latenz
Beachte, dass die Blockchain-Latenz aufgrund der Konsensanforderungen des Netzwerks von Natur aus schwankt. Konzentriere dich auf relative Performance-Unterschiede und Konsistenz statt auf absolute Werte.