--- title: "FAQ - Latenz und Regionen" description: "Häufig gestellte Fragen zu Latenz und Regionen bei ERPC, in zwei Teilen: nicht chainspezifische Fragen, dann Antworten, die auf Solanas Funktionsweise beruhen." canonical: "https://erpc.global/de/faq/latency/general/" locale: "de" --- # FAQ - Latenz und Regionen Fragen zu Abrechnung, Free-Plan, Zahlung sowie 401- und 429-Fehlern finden Sie unter [So starten Sie](https://erpc.global/de/faq/how-to-start/general/). ## Nicht an eine bestimmte Chain gebunden Diese Fragen behandeln, wie Entfernung, Region, Serverstandort, geteilte oder dedizierte Endpunkte und die Programmiersprache Ihres Clients die Latenz beeinflussen. ### Q. Muss ich eine Region wählen? Mit [Edge RPC](https://erpc.global/de/doc/rpc/edge/) müssen Sie keine Region wählen. Eine Anwendung, die sich mit edge.erpc.global verbindet, wird automatisch zu einem nahe gelegenen Einstiegspunkt auf dem Netzwerkpfad geleitet. Bei Unlimited Endpoints für Solana, Ethereum und Avalanche C-Chain wählen Sie die Region bei der Bestellung, nahe dem Ort, an dem Ihr Handelssystem oder Backend läuft. Die verfügbaren Regionen prüfen Sie bei der Bestellung im [ERPC Web Dashboard](https://dashboard.erpc.global/de). Auf Solana passt keine einzelne Region zu jeder Strategie, weil die Leader-Rolle gemäß dem Leader-Schedule zwischen den Validatoren wechselt; siehe den Abschnitt Solana weiter unten. ### Q. Ich habe eine hohe Latenz. Warum? Greifen Sie von einem physisch nahe gelegenen Standort auf den Endpunkt zu? Die Entfernung wirkt sich erheblich auf die Latenz aus. Wir empfehlen, von Servern in der Nähe des bereitgestellten Endpunkts aus zuzugreifen. Theoretisch bietet unser Netzwerk die schnellsten Verbindungen über unsere [Bare-Metal-Server](https://erpc.global/de/baremetal/) und [VPS-Dienste](https://erpc.global/de/vps/). ### Q. Wie ist die Latenz? Die Latenz variiert je nach Messmethode und spezifischer Nutzungsumgebung. Statt sich auf exakte Zahlenwerte zu konzentrieren, ist es entscheidend sicherzustellen, dass die Latenz Ihren tatsächlichen betrieblichen Anforderungen entspricht. Für Solana können Sie die Latenz mit diesen Open-Source-Werkzeugen für TypeScript und Rust messen. - [Solana Stream SDK - ValidatorsDAO GitHub](https://github.com/ValidatorsDAO/solana-stream) - [SLV (Deutsch)](https://slv.dev/de) ### Q. Warum sind dedizierte Endpunkte schneller? Geteilte Endpunkte werden von mehreren Kunden genutzt, die sich dieselben Ressourcen teilen. Mit zunehmendem Traffic steigt tendenziell die Latenz. Server-Ressourcen haben physische Grenzen, und die Arbeitslast, die sie bewältigen können, ist endlich. Wenn zu viele Anfragen gleichzeitig eintreffen, müssen sie nacheinander verarbeitet werden, was zu längeren Antwortzeiten führt. Obwohl wir verschiedene Maßnahmen ergreifen, um die Leistung auch auf geteilten Endpunkten zu optimieren, sind Sie bei dedizierten Endpunkten der einzige Nutzer der Ressource. Andere Nutzer haben also keinerlei Einfluss auf Sie, was durchgängig stabile und schnelle Antworten sicherstellt. Darüber hinaus bieten dedizierte Endpunkte Kommunikationsoptionen ohne TLS, etwa HTTP. Da der TLS-Handshake (etwa 20 ms) entfällt, ist die Kommunikation noch schneller als über HTTPS. ### Q. Welcher Plan ist am schnellsten? In der Regel ist unser Plan der höchsten Stufe am schnellsten, da er leistungsstärkere CPUs, mehr Arbeitsspeicher und robuste Hardwarekonfigurationen bietet. Wenn Sie noch leistungsfähigere Server benötigen, bieten wir auch maßgeschneiderte Lösungen an; unsere Standardpläne sind jedoch auf ein optimales Preis-Leistungs-Verhältnis ausgelegt. Wir sind überzeugt, auf jedem Preisniveau Leistung auf Weltklasseniveau zu bieten. Wenn Sie im gleichen Preissegment einen schnelleren Anbieter finden, teilen Sie es uns bitte mit, damit wir der Sache nachgehen und Verbesserungen vornehmen können. ### Q. Die Latenz entspricht nicht meinen Erwartungen. Die Leistung kann je nach verwendeter Programmiersprache erheblich variieren. Typischerweise ergibt sich bei Geschwindigkeitsvergleichen von Programmiersprachen folgende Rangfolge: **Rust > Go > TypeScript (JavaScript) > Python** Ausführlichere Vergleiche finden Sie in der folgenden Ressource: [Geschwindigkeitsvergleich nach Programmiersprache](https://niklas-heer.github.io/speed-comparison/) Wenn maximale Leistung Ihr Ziel ist, empfehlen wir dringend den Einsatz von Rust. ## Solana Diese Antworten beruhen auf der Funktionsweise von Solana: Die Leader-Rolle wechselt gemäß dem Leader-Schedule zwischen den Validatoren, daher prägen die Standorte der Validatoren Ihre Wahl der Region. ### Q. Welche Region empfehlen Sie? Es gibt keine einzelne Region, die dauerhaft die beste ist. Solana ist global, und die Leader-Rolle wechselt gemäß dem Leader-Schedule zwischen den Validatoren. In Regionen mit mehr Validatoren und höherem Stake fallen Leader-Slots häufiger an, was dazu beitragen kann, dass Transaktionen schneller in einen Block aufgenommen werden. Der Nachteil: Auch der konkurrierende Traffic konzentriert sich dort, sodass eine weniger überlaufene Region je nach Strategie manchmal bessere Ergebnisse liefern kann. Ein praktischer Ausgangspunkt: Wählen Sie eine Region mit hoher Validatordichte wie Frankfurt oder die US-Ostküste, wenn ein stetiges Angebot an Leader-Slots am wichtigsten ist, oder platzieren Sie sich in der Nähe eines bestimmten Ziel-Validators, wenn die Ausführung über den kürzesten Pfad Vorrang hat. Nutzen Sie [Validators Solutions](https://validators.solutions/), um die öffentliche Verteilung des Solana-Netzwerks zu verstehen, und entscheiden Sie dann anhand der [ERPC Leader Slot API](https://erpc.global/de/doc/rpc/leader-slot-api/) und realer Messungen, ob eine Bereitstellung in einer Region, in zwei Regionen oder global sinnvoll ist. [![Bericht zur Verteilung des Solana-Mainnets](https://erpc.global/faq/SolanaMainnetReportEN.jpg)](https://validators.solutions/) ### Q. Ich brauche eine Latenz von ~400 ms oder besser. Um eine Latenz innerhalb von etwa 400 ms zu erreichen, sollten Sie diese wesentlichen Punkte berücksichtigen: - **Realistisches Verständnis von Ping-Werten**: Ping-Werte geben ideale Bedingungen wieder und spiegeln nicht die tatsächliche Latenz bei Streaming-Kommunikation wider, die typischerweise etwa das Fünffache der Ping-Latenz beträgt. Ein Ping von 100 ms zwischen Kontinenten führt beispielsweise realistisch betrachtet zu etwa 500 ms Latenz. Um ~400 ms Latenz zu erreichen, muss die Infrastruktur daher in derselben Region aufgebaut werden. - Typische Ping-Referenzwerte: - Gleiches Netzwerk: ~0,1 ms - Private Network Interconnect (PNI): ~0,2 ms - Gleiches Rechenzentrum: ~0,3 ms - Gleiche Stadt: ~1 ms - Nachbarland: ~5–10 ms - Interkontinental: ~100–300 ms - **Die Durchschnittslatenz-Falle vermeiden**: Solana-Validatoren sind geografisch über die ganze Welt verteilt, und der Leader-Schedule ändert sich mit jeder Epoche zufällig. Sich auf die durchschnittliche Latenz zu verlassen, um ~400 ms zu erreichen, ist nicht praktikabel. Verfolgen Sie stattdessen die Schedules der Validatoren in Ihrer jeweiligen Region genau, um die Slots mit der niedrigsten Latenz zu identifizieren. Um durchgängig minimale Latenz zu erreichen, ist Infrastruktur in allen relevanten Regionen erforderlich. In derselben Region kann die Datenerfassung binnen einiger Dutzend Millisekunden erfolgen, und die Übertragung ist in nur wenigen Millisekunden möglich. - **Den Leader-Schedule verfolgen**: Beobachten Sie den Leader-Schedule der Validatoren für Ihre Region mit der **ERPC Leader Slot API (`getLeaderSlots`)**. Die API liefert den anstehenden Leader-Schedule, die Stake-Gewichtung für die aktuelle Epoche, geschätzte Standorte der Validatoren und Referenz-Ping-Werte, sodass Sie die Slots mit der niedrigsten Latenz als Ziel bestimmen können, bevor sie an der Reihe sind. Öffentliche Daten im Kartenstil und native RPC-APIs eignen sich für einen breiten Überblick über das Netzwerk, sind für das Timing der Ausführung aber nicht präzise genug. Die Leader Slot API schließt diese Lücke mit der Granularität, die für Routing- und Trading-Entscheidungen nötig ist. - [Dokumentation zur ERPC Leader Slot API](https://erpc.global/de/doc/rpc/leader-slot-api/) - [ERPC Web Dashboard](https://dashboard.erpc.global/de) [![Validators Solutions - Solana-Netzwerkdaten](https://erpc.global/faq/ValidatorsSolutionsEN.jpg)](https://validators.solutions/) Solana-Netzwerkdaten: [Validators Solutions](https://validators.solutions/) ### Q. Wie kann ich Zero-Block-Trading (Zero-Slot-Trading) erreichen? Für erfolgreiches Zero-Block-Trading (Zero-Slot-Trading) sind ausgefeiltere Strategien nötig: - **Opportunity Zones identifizieren**: Solana-Validatoren sind weltweit verteilt, und es ist physikalisch unmöglich, für jeden Slot eine optimale Latenz zu erreichen. Beobachten Sie daher die Leader-Schedules der Validatoren in der Region, in der sich Ihre Infrastruktur befindet, und identifizieren Sie die günstigsten Opportunity Zones. Auch eine Verteilung der Infrastruktur auf mehrere Regionen kann von Vorteil sein. Frankfurt etwa ist dank seiner hohen Validatordichte eine Schlüsselregion: Leader werden dort häufiger ausgewählt, was mehr Trading-Möglichkeiten eröffnet. Nutzen Sie die **ERPC Leader Slot API (`getLeaderSlots`)**, um den anstehenden Leader-Schedule, die Stake-Gewichtung für die aktuelle Epoche, geschätzte Standortdaten der Validatoren und Referenz-Ping-Werte mit weitaus höherer Präzision abzurufen als über öffentliche Datenquellen im Kartenstil oder native RPC-APIs. So können Sie Opportunity Zones ermitteln, bevor die Slots an der Reihe sind, und Trades mit nahezu null Latenz ausführen. - [Dokumentation zur ERPC Leader Slot API](https://erpc.global/de/doc/rpc/leader-slot-api/) - [ERPC Web Dashboard](https://dashboard.erpc.global/de) - **Dedizierte Knoten einsetzen**: Wenn Sie Schwierigkeiten haben, im Wettbewerb mitzuhalten, sollten Sie dedizierte Knoten in Betracht ziehen. Bei geteilten Knoten entsteht durch den Traffic anderer Nutzer Latenz; sie werden daher nicht empfohlen. Wenn Sie Ihren dedizierten Knoten zudem im selben Netzwerk wie Ihre Anwendung platzieren, sinkt die Netzwerklatenz erheblich und die Performance wird optimiert. ### Q. Was ist am schnellsten: WebSockets, gRPC oder Shreds? Das Feedback vieler Kunden ist recht einheitlich, und die Rangfolge der Leistung sieht wie folgt aus: **Shreds > gRPC > WebSockets** Wenn Sie abweichende Ergebnisse oder Bedingungen feststellen, teilen Sie uns dies bitte mit. ### Q. Ist dieser RPC (gRPC, Shreds) schneller als andere? Wir legen jede Preisstufe auf Geschwindigkeit aus und freuen uns, wenn das im direkten Vergleich mit jedem anderen Anbieter gemessen wird. Die Ergebnisse können je nach Region variieren, ebenso je nachdem, ob Sie einen geteilten oder einen dedizierten Endpunkt nutzen, welches Protokoll Sie verwenden (WebSockets, gRPC oder Shreds) und in welcher Programmiersprache Ihr Client läuft. Wenn Ihnen unser Dienst langsamer erscheint, nennen Sie uns bitte über das ERPC Web Dashboard die konkreten Bedingungen und die Wettbewerber, mit denen Sie ihn verglichen haben. Wir ermitteln die Ursache und verbessern die Geschwindigkeit weiter. [ERPC Web Dashboard](https://dashboard.erpc.global/de)