--- title: "FAQ - Geyser gRPC-Stream" description: "Häufig gestellte Fragen zum ERPC - Enhanced Solana-RPC Geyser gRPC-Stream" canonical: "https://erpc.global/de/faq/grpc/general/" locale: "de" --- # FAQ - Geyser gRPC-Stream ## Q. In welchen Regionen liegen Ihre Knoten? Aktuell betreiben wir Knoten in den folgenden Regionen: - Frankfurt (FRA) - Amsterdam (AMS) - London (LON) - New York (NY) - Tokio (TY) - Singapur (SGP) - Sydney (SYD) ERPC misst die tatsächliche Netzwerklatenz anhand realer Routing-Pfade und wählt automatisch die Region mit der niedrigsten Latenz, statt sich auf die Luftlinienentfernung zu verlassen. Dieser Ansatz verbessert nicht nur die Latenz für einzelne Nutzer, sondern steigert auch die Effizienz des gesamten Netzwerks und stärkt die globale Widerstandsfähigkeit von ERPC gegen potenzielle Angriffe. Wenn Ihre Umgebung die optimale Region nicht automatisch auswählt, kontaktieren Sie uns bitte über das ERPC Web Dashboard. ERPC Web Dashboard: https://dashboard.erpc.global/de ## Q. Die Latenz wird mit 9999 ms angezeigt, und es wird eine nicht optimale Region ausgewählt. Was soll ich tun? Für die Regionsauswahl von gRPC sendet ERPC von den unten aufgeführten Proxy-Hosts ICMP-Latenzprüfungen an Ihre registrierte IP-Adresse. Lassen Sie eingehende ICMP-Echoanfragen von allen aufgeführten Quell-IP-Adressen zu. Werden sie durch eine Firewall (ufw, Cloud-Firewall, Sicherheitsgruppe usw.) blockiert, kann der Messwert `9999ms` betragen und eine nicht optimale Region ausgewählt werden. Mehrere IP-Adressen in einer Region gehören zu separaten Prüfhosts; sie werden alle benötigt. [ERPC_PING_SOURCES:grpc]: # | Region | ICMP-Quell-IP-Adressen | | --- | --- | | 🇳🇱 Amsterdam | `82.21.43.34`, `151.244.92.36` | | 🇺🇸 New York | `151.243.244.5` | | 🇩🇪 Frankfurt | `151.241.178.20`, `151.241.178.34`, `151.241.178.21` | | 🇬🇧 London | `151.241.65.4` | | 🇯🇵 Tokyo | `143.20.238.66` | | 🇸🇬 Singapore | `151.245.186.2` | | 🛰️ Far Point | `143.20.238.73` | ## Q. Ich habe meine IP freigegeben, kann mich aber immer noch nicht verbinden. Was soll ich prüfen? Verwenden Sie den im Dashboard ausgewählten verschlüsselten HTTPS-Endpunkt. HTTPS nutzt Port 443; HTTP auf Port 80 bleibt die unverschlüsselte Option mit niedriger Latenz. Beide Transportarten verwenden dieselbe Allowlist registrierter IPs. Verwenden Sie den im Dashboard ausgewählten Endpunkt: HTTPS auf 443 oder HTTP auf 80. - HTTPS-Endpunkt: Verwenden Sie den im Dashboard ausgewählten Endpunkt auf Port 443. - HTTP-Endpunkt: Verwenden Sie den im Dashboard ausgewählten Endpunkt auf Port 80. - Verwenden Sie die im Dashboard angezeigte URL mit `https://` oder `http://`. Die Authentifizierung erfolgt über Ihre registrierte IP-Adresse. Fügen Sie keine `x-token`-, `token`- oder `Authorization`-Header hinzu, sofern dies nicht auf einer bestimmten Produktseite ausdrücklich steht. ## Q. Ich habe bisher nur WebSocket verwendet. Kann ich gRPC nutzen? Haben Sie Beispiele? Ja. Mit SLV können Sie gRPC schnell testen und mit der Entwicklung beginnen. Für einen geteilten Endpunkt, den Sie ohne Token testen können, führen Sie Folgendes aus: ```bash slv check grpc --endpoint --token none ``` Details finden Sie in unserer [gRPC-Schnellstartanleitung](https://slv.dev/de/doc/geyser-grpc/quickstart/). ## Q. Kann ich zwei IP-Adressen registrieren? Sie können einen Endpunkt pro Abonnement verwenden. Wenn Sie zwei IP-Adressen verwenden möchten, müssen Sie zwei separate Abonnements abschließen. ## Q. Gibt es Filtergrenzen? Shared Geyser gRPC verwendet Fair-Use-Schutz, damit ein Stream nicht die Ressourcen verbraucht, die andere ERPC-Kunden benötigen. Nach der aktuellen Shared-Regel wird jede nicht leere `blocks`-Map abgelehnt, auch eine enge Blockanfrage. Jeder Account-Filter muss `account`, `owner` oder einen unterstützten Cuckoo-Filter enthalten; `memcmp` oder `dataSize` allein reichen nicht aus. Entfernen Sie eine abgelehnte Form und abonnieren Sie nur die Daten, die Ihre Anwendung benötigt. Eine Transaktions-Subscription oder Block-Metadaten können passen, ohne einen vollständigen Block zu übertragen. Dedicated Geyser gRPC ist passend, wenn ein legitimer Workload die Shared-Grenze für Form oder Ressourcen überschreitet; ungültige Parameter oder einen langsamen Client repariert es nicht. ## Q. Wie sammle ich einen gRPC-Fehler, bevor ich die Verbindung wiederherstelle? Bewahren Sie den ersten Fehler auf, bevor eine Reconnect-Schleife ihn ersetzt. Notieren Sie gRPC-Status und -Meldung aus initialen Metadaten und Trailern sowie `x-erpc-error-code`, `x-erpc-error-reason` und `x-erpc-doc-url`. Bei einer ERPC-Pause notieren Sie außerdem `x-erpc-retry-after-seconds` und `x-erpc-retry-at` (Unix-Sekunden). Ein Fehler kann als `ERPC [STREAM_GUARD_SLOW_READER]: ...` erscheinen. Fügen Sie den angezeigten Fehler oder seinen Code in die FAQ-Suche ein. Die kanonische Erklärung steht in den [ERPC gRPC-FAQ](https://erpc.global/de/faq/grpc/general/). Verlassen Sie sich nicht darauf, dass bei einem frühen Verbindungsende ein Trailer ankommt. Sie können auch nach Symptomen suchen: langsamer Empfänger, getrennt, Bandbreite, Zustellverzögerung, Rückstand, Pause, Wiederholung, ungültiges Argument, Ressource erschöpft, Berechtigung verweigert, IP-Registrierung, zu viele Streams, vollständige Blöcke oder alle Accounts. ## Q. Welche gRPC-Fehler pausieren meine Verbindung, und wann sollte mein Client mit dem Wiederverbinden aufhören? Eine Pause ist ein befristeter Zeitraum, den ERPC nach bestimmten Fehlern festlegt. Solange sie läuft, darf sich der Client nicht wiederverbinden. **Was gezählt wird.** Diese Fehler werden gezählt und teilen sich eine Stufenfolge: - Jede Subscribe-Anfrage, die ERPC mit `ERPC_GRPC_INVALID_ARGUMENT`, `STREAM_GUARD_SHAPE_BLOCKS` oder `STREAM_GUARD_SHAPE_ACCOUNTS_ALL` ablehnt, die erste eingeschlossen. Der erste gezählte Fehler ist die Warnung, die keine Pause auslöst. - `STREAM_GUARD_SLOW_READER`. Ausnahme: Entsteht die Zustellverzögerung auf der Seite von ERPC, schließt ERPC den Stream, ohne dass dies gezählt wird, und der Fehler enthält keine Retry-Frist. Nicht gezählt werden: das Wiederverbinden selbst, die vier Codes `STREAM_ADMISSION_*` (`STREAM_ADMISSION_LIMIT_REACHED`, `STREAM_ADMISSION_IP_NOT_ADMITTED`, `STREAM_ADMISSION_SOURCE_UNAVAILABLE` und `STREAM_ADMISSION_SNAPSHOT_UNAVAILABLE`) sowie jeder gezählte Fehler, der auftritt, während eine Pause läuft. Ein gezählter Fehler während einer Pause verlängert die Pause nicht und rückt nicht auf die nächste Stufe vor. **Die Stufen.** Jeder gezählte Fehler rückt in dieser Reihenfolge um eine Stufe vor, beginnend mit der Warnung: - Warnung: keine Pause. - Pause von 60 Sekunden. - Pause von 300 Sekunden. - Pause von 1800 Sekunden. - Pause von 86400 Sekunden (24 Stunden). Dies ist die letzte Stufe: Auf ihr löst jeder gezählte Fehler eine weitere Pause von 86400 Sekunden aus. Auf der Warnstufe rückt der nächste gezählte Fehler nur dann zur Pause von 60 Sekunden vor, wenn er innerhalb von 1 Stunde nach der Warnung kommt. Ein gezählter Fehler, der mehr als 1 Stunde nach der Warnung kommt, ist eine weitere Warnung ohne Pause, und das 1-Stunden-Fenster läuft dann ab dieser neuen Warnung. Ein gezählter Fehler, der weniger als 60 Sekunden nach dem letzten gezählten Fehler kommt, zählt als Teil dieses Fehlers und rückt um keine Stufe vor. **Wann die Stufen zur Warnung zurückkehren.** Sobald die Stufen eine Pause ausgelöst haben, kehren sie erst nach 24 Stunden ohne gezählten Fehler und ohne Pause zur Warnung zurück, gemessen ab dem Ende der letzten Pause; der nächste gezählte Fehler danach ist eine Warnung ohne Pause. Bis dahin löst der nächste gezählte Fehler sofort die nächste Stufe aus, ohne Warnung. **Die Egress-Pause.** `STREAM_GUARD_EGRESS_BUDGET` löst eine eigene feste Pause von 600 Sekunden aus. Dieser Fehler führt nicht zur nächsten Stufe. **Wo die Endzeit steht.** - Der Fehler, der eine Pause auslöst, enthält `Retry after N seconds.` sowie die Header `x-erpc-retry-after-seconds` und `x-erpc-retry-at` (Unix-Sekunden). Die Warnung enthält keine Retry-Frist. - Wenn eine gezählte abgelehnte Anfrage diejenige ist, die eine Pause auslöst, kommt sie nicht mit ihrem eigenen Code zurück, sondern als `STREAM_GUARD_SHAPE_REJECT_PENALTY` mit `ResourceExhausted (8)`. - Während einer Pause wegen eines langsamen Lesers oder einer Egress-Pause erhält eine Wiederverbindung `STREAM_GUARD_PENALTY_ACTIVE` mit der Restzeit. - Während einer Pause, die durch eine abgelehnte Anfrage ausgelöst wurde, wird eine neue Verbindung sofort geschlossen, ohne gRPC-Status und ohne ERPC-Code. Eine Anfrage auf einer Verbindung, die noch offen ist, kann erneut mit `STREAM_GUARD_SHAPE_REJECT_PENALTY` und der Restzeit beantwortet werden, bevor diese Verbindung geschlossen wird. Der Client sieht die Endzeit möglicherweise nie wieder, daher muss er `x-erpc-retry-at` aus dem ersten Fehler speichern, der ihn enthält. | Code | gRPC-Status | Löst eine Pause aus oder führt zur nächsten Stufe? | Was der Client tun muss | | --- | --- | --- | --- | | `ERPC_GRPC_INVALID_ARGUMENT` | `InvalidArgument (3)` | Ja, wenn er eine Subscribe-Anfrage ablehnt. Er ist dann ein gezählter Fehler im Sinne der oben beschriebenen Stufen. | Beenden Sie die Schleife und senden Sie dieselbe Anfrage nicht erneut. Sein eigener Eintrag weiter unten nennt, was zu prüfen ist. | | `STREAM_GUARD_SHAPE_BLOCKS` | `PermissionDenied (7)` | Ja. Er ist ein gezählter Fehler im Sinne der oben beschriebenen Stufen. | Beenden Sie die Schleife und senden Sie dieselbe Anfrage nicht erneut. Sein eigener Eintrag weiter unten nennt, was zu prüfen ist. | | `STREAM_GUARD_SHAPE_ACCOUNTS_ALL` | `PermissionDenied (7)` | Ja. Er ist ein gezählter Fehler im Sinne der oben beschriebenen Stufen. | Beenden Sie die Schleife und senden Sie dieselbe Anfrage nicht erneut. Sein eigener Eintrag weiter unten nennt, was zu prüfen ist. | | `STREAM_GUARD_SLOW_READER` | `ResourceExhausted (8)` | Ja. Er ist ein gezählter Fehler im Sinne der oben beschriebenen Stufen. Ausnahme: Entsteht die Zustellverzögerung auf der Seite von ERPC, schließt ERPC den Stream, ohne dass dies gezählt wird, und der Fehler enthält keine Retry-Frist. | Beenden Sie die Schleife. Sein eigener Eintrag weiter unten nennt, was zu prüfen ist. Wenn er eine Pause ausgelöst hat, verbinden Sie sich nicht vor der Zeit in `x-erpc-retry-at` wieder. | | `STREAM_GUARD_EGRESS_BUDGET` | `ResourceExhausted (8)` | Ja. Er löst eine feste Pause von 600 Sekunden außerhalb der oben beschriebenen Stufen aus. | Verbinden Sie sich nicht vor der Zeit in `x-erpc-retry-at` wieder. Sein eigener Eintrag weiter unten nennt, was zu prüfen ist. | | `STREAM_GUARD_SHAPE_REJECT_PENALTY` | `ResourceExhausted (8)` | Ja. Er ist die gezählte abgelehnte Anfrage, die eine Pause ausgelöst hat. Er kann auf einer Verbindung, die noch offen ist, erneut mit der Restzeit zurückkommen. | Verbinden Sie sich nicht vor der Zeit in `x-erpc-retry-at` wieder. Korrigieren Sie die abgelehnte Anfrage und senden Sie sie nicht unverändert erneut. | | `STREAM_GUARD_PENALTY_ACTIVE` | `ResourceExhausted (8)` | Nein. Er meldet eine Pause wegen eines langsamen Lesers oder eine Egress-Pause, die bereits läuft. | Verbinden Sie sich nicht vor der Zeit in `x-erpc-retry-at` wieder. | | `STREAM_ADMISSION_LIMIT_REACHED` | `ResourceExhausted (8)` | Nein. Er hat keine zeitgesteuerte Pause. | Schließen Sie ungenutzte Streams und versuchen Sie es dann erneut. | | `STREAM_ADMISSION_IP_NOT_ADMITTED` | `PermissionDenied (7)` | Nein. Er hat keine zeitgesteuerte Pause. | Sein eigener Eintrag weiter unten nennt, was zu prüfen ist. | | `STREAM_ADMISSION_SOURCE_UNAVAILABLE` | `Unavailable (14)` | Nein. Er hat keine zeitgesteuerte Pause. | Warten Sie wie üblich mit Backoff und versuchen Sie es nach einer Verzögerung erneut. | | `STREAM_ADMISSION_SNAPSHOT_UNAVAILABLE` | `Unavailable (14)` | Nein. Er hat keine zeitgesteuerte Pause. | Warten Sie wie üblich mit Backoff und versuchen Sie es nach einer Verzögerung erneut. | **Was der Client tun muss.** Beenden Sie bei einem gezählten Fehler die Schleife, senden Sie dieselbe Anfrage nicht erneut und korrigieren Sie sie. Verbinden Sie sich während einer Pause nicht vor der Zeit in `x-erpc-retry-at` wieder. Abgelehnte Subscribe-Anfragen werden nach den obigen Regeln gezählt, das Wiederverbinden nicht. ## Q. Was bedeutet `STREAM_GUARD_SLOW_READER` mit `ResourceExhausted (8)`, wenn ein langsamer Empfänger getrennt wird? ERPC hat für diesen Stream zu wenig Schreibfortschritt oder eine Zustellverzögerung beobachtet. Allein aus der Zustellverzögerung lässt sich die Ursache nicht bestimmen. Prüfen Sie Paketverluste, effektive Bandbreite, Host-Kapazität und ob der Anwendungskonsument Schritt hält. Grenzen Sie die abonnierten Daten ein und verschieben Sie die Verarbeitung aus der Empfangsschleife in eine begrenzte Queue. Eine begrenzte Queue kontrolliert den Speicher, kann aber keinen dauerhaft langsamen Konsumenten beheben. Warten Sie vor der Wiederverbindung auf eine von ERPC gelieferte Retry-Frist. Die Frage „Warum bleibt mein gRPC-Stream bei gleichbleibender Geschwindigkeit und fällt zurück?“ unten erklärt das Empfangsfenster und wie Sie es in Ihrer Client-Bibliothek vergrößern. ## Q. Warum bleibt mein gRPC-Stream bei gleichbleibender Geschwindigkeit und fällt zurück? Ein kleines Empfangsfenster in Ihrem Client oder in etwas, das zwischen ihm und ERPC liegt, kann Trennungen mit `STREAM_GUARD_SLOW_READER` und die darauf folgenden Pausen verursachen. Diese Antwort erklärt, was ein Empfangsfenster ist, wie Sie erkennen, ob es Ihren Stream begrenzt, und wie Sie es je nach Bibliothek vergrößern. Die Frage „Welche gRPC-Fehler pausieren meine Verbindung, und wann sollte mein Client mit dem Wiederverbinden aufhören?“ oben nennt die Stufen und ihre Dauer. **Was ein Empfangsfenster ist.** Bei HTTP/2 teilt der Empfänger dem Sender mit, wie viele Daten gesendet werden dürfen, bevor der Empfänger den Erhalt bestätigt; diese Menge ist das Empfangsfenster (das Flusskontrollfenster von HTTP/2). Ein Round-Trip transportiert höchstens ein Fenster, daher erreicht die Geschwindigkeit höchstens etwa das Fenster geteilt durch die Round-Trip-Zeit (der Weg zum Endpunkt und zurück). **Die anderen Grenzen.** Es gibt zwei Fenster, eines pro Stream und eines pro Verbindung (alle Streams einer Verbindung teilen es sich), und das kleinere bestimmt die Grenze. In der HTTP/2-Spezifikation beginnen beide Fenster bei 65.535 Bytes. Der TCP-Empfangspuffer (Speicher für eingehende Daten) begrenzt die Geschwindigkeit auf dieselbe Weise. Ein Proxy, Load Balancer, Gateway, VPN oder Sidecar dazwischen hat eigene Fenster und Puffer. Ist dort ein Fenster oder Puffer klein, deckelt das den Stream, auch wenn die Fenster Ihres eigenen Clients groß sind. **So sieht es aus.** Ein einzelner Stream pendelt sich bei nahezu derselben Geschwindigkeit ein, egal wie stark die Blockchain ausgelastet ist, und seine Zustellverzögerung wächst stetig. ERPC hat von einem Ort mit einer Round-Trip-Zeit von etwa 6 ms zum Shared-Endpunkt in Frankfurt gemessen und zwischen den Durchläufen nur das Fenster geändert: - Stream-Fenster 16 KiB: konstant bei etwa 2,7 MB/s (16 KiB geteilt durch 6 ms); die Zustellverzögerung wuchs um etwa 0,6 Sekunden pro Sekunde und erreichte nach 45 Sekunden 26 Sekunden. - Beide 16 MiB: Die maximale Zustellverzögerung betrug 14 ms. Entsteht die Zustellverzögerung auf der Seite von ERPC, schließt ERPC den Stream, ohne dass dies gezählt wird, und der Fehler enthält keine Retry-Frist. **So prüfen Sie es.** 1. Vergleichen Sie Geschwindigkeit und Zustellverzögerung des Streams mit dem Muster oben. 2. Messen Sie die Round-Trip-Zeit. Multiplizieren Sie die Geschwindigkeit des Streams mit der Round-Trip-Zeit, um das Fenster zu schätzen (2,7 MB/s mal 6 ms ergibt etwa 16 KB). 3. Prüfen Sie, ob eines der beiden Fenster Ihres Clients auf einen kleinen Wert gesetzt ist oder ob das automatische Wachstum (die Bibliothek vergrößert das Fenster selbst) abgeschaltet ist. 4. Prüfen Sie den TCP-Empfangspuffer. Führen Sie unter Linux `sysctl net.ipv4.tcp_rmem net.core.rmem_max` aus und sehen Sie nach, ob Ihre Anwendung `SO_RCVBUF` setzt, was die automatische Größenanpassung abschaltet. 5. Prüfen Sie die Fenster und Puffer von allem, was dazwischen liegt. 6. Hat die Geschwindigkeit keine Obergrenze und wächst nur die Verzögerung, ist die Verarbeitung nach dem Empfang langsam. Die Frage „Was bedeutet `STREAM_GUARD_SLOW_READER` mit `ResourceExhausted (8)`, wenn ein langsamer Empfänger getrennt wird?“ oben erklärt, wie Sie die Empfangsschleife auf das Lesen beschränken und schwere Arbeit in eine begrenzte Queue verlagern. **Einstellungen je Bibliothek.** Die Beispiele setzen beide Fenster auf 16 MiB, wie in der Messung von ERPC. Bei einer hier nicht aufgeführten Bibliothek suchen Sie nach den Einstellungen für das initiale HTTP/2-Fenster. **Rust, `yellowstone-grpc-client`.** Ohne Fenstereinstellungen verwendet `GeyserGrpcClient::build_from_shared` 2 MiB pro Stream und 5 MiB pro Verbindung. Bei einem Round-Trip von 6 ms erlauben diese Standardwerte mehr als 300 MB/s, deckeln den Stream also nicht. Um die Fenster selbst festzulegen, verwenden Sie die beiden Builder-Methoden und lassen `http2_adaptive_window` ausgeschaltet. Ist es eingeschaltet, beginnt das Fenster bei 65.535 Bytes und wächst selbst bis auf 16 MiB, ohne Ihre Werte zu beachten. ```rust // Beide Fenster fest auf 16 MiB; http2_adaptive_window ausgeschaltet lassen. let client = GeyserGrpcClient::build_from_shared(endpoint)? .tls_config(ClientTlsConfig::new().with_native_roots())? .initial_stream_window_size(16 * 1024 * 1024) .initial_connection_window_size(16 * 1024 * 1024) .connect() .await?; ``` **TypeScript, `@triton-one/yellowstone-grpc` 5.0.1 oder neuer.** Standardwerte: 4 MiB pro Stream, 8 MiB pro Verbindung, automatisches Wachstum eingeschaltet. Das Fenster beginnt bei 64 KiB und wächst bis auf 16 MiB, daher deckeln die Standardwerte den Stream selten. Um die Größen festzulegen, übergeben Sie das dritte Argument mit `grpcHttp2AdaptiveWindow: false`. ```typescript // Adaptives Fenster aus, daher gelten diese festen Größen. const client = new Client(endpoint, undefined, { grpcInitialStreamWindowSize: 16 * 1024 * 1024, grpcInitialConnectionWindowSize: 16 * 1024 * 1024, grpcHttp2AdaptiveWindow: false, }) ``` **TypeScript, `@triton-one/yellowstone-grpc` 5.0.0 oder älter.** Diese Versionen verwenden `@grpc/grpc-js`, dessen Standardfenster 65.535 Bytes beträgt: etwa 11 MB/s bei 6 ms, etwa 0,66 MB/s bei 100 ms. Ab Version 1.14 wendet `@grpc/grpc-js` die Option `'grpc-node.flow_control_window'` auf beide Fenster an; Version 1.13 wendet sie nur auf das Stream-Fenster an, sodass das Verbindungsfenster bei 65.535 Bytes bleibt (etwa 11 MB/s bei 6 ms). Mit `@grpc/grpc-js` vor Version 1.14 ist das Update auf `@triton-one/yellowstone-grpc` 5.0.1 oder neuer der schnellere Weg. ```typescript // Erfordert @grpc/grpc-js 1.14 oder neuer, um beide Fenster zu vergrößern. const client = new Client(endpoint, undefined, { 'grpc-node.flow_control_window': 16 * 1024 * 1024, }) ``` **Go, `google.golang.org/grpc`.** Standardmäßig vergrößert die Bibliothek die Fenster selbst, bis auf 16 MiB. `grpc.WithInitialWindowSize` und `grpc.WithInitialConnWindowSize` legen sie fest und schalten das automatische Wachstum ab; Werte unter 64 KiB werden ignoriert. Setzen Sie beide: Ist nur eine Option gesetzt, bleibt das andere Fenster bei 64 KiB. ```go // Beide setzen; das schaltet auch das automatische Fensterwachstum ab. conn, err := grpc.NewClient(target, grpc.WithTransportCredentials(creds), grpc.WithInitialWindowSize(16<<20), grpc.WithInitialConnWindowSize(16<<20), ) ``` **Python, `grpcio`.** `grpc.http2.bdp_probe` ist standardmäßig eingeschaltet, daher wachsen die Fenster selbst; wenn Ihr Code `("grpc.http2.bdp_probe", 0)` übergibt, entfernen Sie das. `grpc.http2.lookahead_bytes` legt das Vorauslesen pro Stream fest (Standard 64 KB); größere Werte können bei einem langen Round-Trip helfen. ```python # Wenn Ihre Optionen ("grpc.http2.bdp_probe", 0) enthalten, entfernen Sie diesen Eintrag. channel = grpc.secure_channel(target, creds, options=[ ("grpc.http2.lookahead_bytes", 16 * 1024 * 1024), ]) ``` **Näher empfangen.** Mit einem kürzeren Round-Trip liefert dasselbe Fenster mehr, und mit dem [VPS-Dienst](https://erpc.global/de/vps/) und den [Bare-Metal-Servern](https://erpc.global/de/baremetal/) von ERPC steht der Client nahe am Endpunkt. **Mit Bedacht aufteilen.** Standard erlaubt 10 Streams und Premium 50, jeweils pro registrierter Quell-IP. Jeder Stream erhält sein eigenes Stream-Fenster, aber die Streams einer Verbindung teilen sich ein Verbindungsfenster, sodass ein kleines Verbindungsfenster die Geschwindigkeit weiterhin begrenzt. Wenn Sie einen Stream ersetzen, schließen Sie zuerst den alten: Offene Streams werden auf das Limit angerechnet, und beim Überschreiten kommt `STREAM_ADMISSION_LIMIT_REACHED` zurück (dazu gibt es weiter unten eine eigene Frage). Aufteilen beschleunigt keine langsame Verarbeitung. ## Q. Was bedeutet `STREAM_GUARD_EGRESS_BUDGET` mit `ResourceExhausted (8)`? Der gesamte Traffic der IP hat die Shared-Grenze überschritten, daher können verbundene Streams gemeinsam schließen. Verringern Sie Datenmenge und unnötige parallele Streams und warten Sie bis zur zurückgegebenen Frist. Diese Egress-Pause dauert fest 600 Sekunden und erhöht die Strafleiter nicht; eine bereits bestehende längere Pause kann jedoch weiter gelten. ## Q. Was bedeutet `STREAM_GUARD_PENALTY_ACTIVE` mit `ResourceExhausted (8)`? Eine frühere Pause wegen eines langsamen Lesers oder eine frühere Egress-Pause läuft noch, und diese Antwort enthält die Restzeit. Bewahren Sie den ersten ERPC-Fehler auf, beheben Sie seine Ursache und verbinden Sie sich nicht vor `x-erpc-retry-at` wieder; testen Sie nicht durch vorzeitiges Wiederverbinden. Wiederverbindungsversuche werden nicht gezählt. Die Frage „Welche gRPC-Fehler pausieren meine Verbindung, und wann sollte mein Client mit dem Wiederverbinden aufhören?“ oben nennt die Stufen und ihre Dauer. ## Q. Was bedeutet `STREAM_GUARD_SHAPE_BLOCKS` mit `PermissionDenied (7)`? Die aktuelle Shared-Regel lehnt jede nicht leere `blocks`-Map ab, auch bei einer engen Anfrage. Entfernen Sie die `blocks`-Map. Verwenden Sie Transaktionen und/oder Block-Metadaten, wenn sie den Bedarf erfüllen; keines von beiden entspricht einem vollständigen Block. Für vollständige Blöcke ist Dedicated Geyser gRPC erforderlich; daraus folgt nicht, dass ein selektiver Blocks-Plan für Shared verfügbar ist. ## Q. Was bedeutet `STREAM_GUARD_SHAPE_ACCOUNTS_ALL` mit `PermissionDenied (7)`? Ein Account-Filtereintrag muss Daten mit `account`, `owner` oder einem unterstützten Cuckoo-Filter auswählen. `memcmp` und `dataSize` allein reichen nicht aus. Grenzen Sie die Account-Anfrage auf eine dieser unterstützten Formen ein oder nutzen Sie Dedicated Geyser gRPC, wenn ein vollständiger Account-Stream erforderlich ist. ## Q. Was bedeutet `STREAM_GUARD_SHAPE_REJECT_PENALTY` mit `ResourceExhausted (8)`? Dieser Code kommt statt `ERPC_GRPC_INVALID_ARGUMENT`, `STREAM_GUARD_SHAPE_BLOCKS` oder `STREAM_GUARD_SHAPE_ACCOUNTS_ALL` zurück, wenn diese gezählte abgelehnte Anfrage diejenige ist, die eine Pause auslöst; die Frage „Welche gRPC-Fehler pausieren meine Verbindung, und wann sollte mein Client mit dem Wiederverbinden aufhören?“ oben erklärt, wann das geschieht. Er enthält `Retry after N seconds.`, `x-erpc-retry-after-seconds` und `x-erpc-retry-at`. Während dieser Pause werden neue Verbindungen sofort geschlossen, ohne gRPC-Status und ohne ERPC-Code, daher sieht der Client die Endzeit möglicherweise nie wieder. Speichern Sie `x-erpc-retry-at` aus dem ersten Fehler, der ihn enthält. Abgelehnte Subscribe-Anfragen werden nach den obigen Regeln gezählt, das Wiederverbinden nicht. Korrigieren Sie die Anfrage und senden Sie sie nicht unverändert erneut. Ein frühes Verbindungsende kann wie ein Transportfehler aussehen; bewahren Sie deshalb den ersten ERPC-Fehler, bevor die Reconnect-Schleife ihn verdeckt. ## Q. Was bedeutet `STREAM_ADMISSION_LIMIT_REACHED` mit `ResourceExhausted (8)`? Die Admission-Kapazität ist derzeit ausgeschöpft. Schließen Sie ungenutzte oder doppelte Streams, prüfen Sie die Kapazität für die Verbindung und versuchen Sie es erneut, wenn Kapazität verfügbar ist. Diese Antwort bedeutet für sich allein keine zeitgesteuerte Strafe. ## Q. Was bedeutet `STREAM_ADMISSION_IP_NOT_ADMITTED` mit `PermissionDenied (7)`? ERPC konnte die Verbindung nicht zulassen, auch nachdem eine Karenzzeit für die IP-Registrierung abgelaufen ist. Vergleichen Sie die tatsächliche ausgehende IP mit der registrierten IP und bestätigen Sie den aktuellen Zugriffsstatus. Lassen Sie eine Registrierungsänderung ohne Annahme einer festen Propagationszeit wirksam werden und wenden Sie sich an den Support, wenn der Zustand anhält. ## Q. Was bedeutet `STREAM_ADMISSION_SOURCE_UNAVAILABLE` mit `Unavailable (14)`? ERPC konnte die Quelle dieser Verbindung zu diesem Zeitpunkt nicht bestimmen. Warten Sie mit Backoff und versuchen Sie es später erneut. Bleibt es bestehen, wenden Sie sich mit dem ersten Fehler und seinen Metadaten an den Support; die Antwort belegt keinen Fehler im Netzwerk oder Server des Kunden. ## Q. Was bedeutet `STREAM_ADMISSION_SNAPSHOT_UNAVAILABLE` mit `Unavailable (14)`? ERPC konnte den Zugang zu diesem Zeitpunkt nicht prüfen. Warten Sie mit Backoff und versuchen Sie es später erneut; bleibt der Zustand bestehen, wenden Sie sich an den Support. Wiederholtes Neuregistrieren, breitere Filter oder der Kauf von Dedicated Geyser gRPC beheben diese Verfügbarkeitsantwort nicht. ## Q. Was bedeutet `ERPC_GRPC_INVALID_ARGUMENT` mit `InvalidArgument (3)`? Die Anfrage enthält ungültige Parameter, Optionen, Feldtypen, Schlüssel oder Filterkombinationen. Reparieren Sie die Anfrage vor dem Wiederholen und senden Sie dieselbe Anfrage nicht erneut. Jede Subscribe-Anfrage, die mit diesem Code abgelehnt wird, ist ein gezählter Fehler nach den Pausenregeln in der Frage „Welche gRPC-Fehler pausieren meine Verbindung, und wann sollte mein Client mit dem Wiederverbinden aufhören?“ oben, gemeinsam mit `STREAM_GUARD_SHAPE_BLOCKS`, `STREAM_GUARD_SHAPE_ACCOUNTS_ALL` und `STREAM_GUARD_SLOW_READER`. Wenn eine solche Anfrage eine Pause auslöst, kommt sie als `STREAM_GUARD_SHAPE_REJECT_PENALTY` mit `ResourceExhausted (8)` zurück. Dedicated Geyser gRPC macht ungültige Parameter nicht gültig. Die Fehlermeldung nennt den Code mit `(reason: )` am Ende, und derselbe Token steht im Antwort-Header `x-erpc-error-reason`. Suchen Sie den Token unten, um zu sehen, was Sie ändern müssen. Wo ein Limit gilt, nennt die Fehlermeldung es. | Reason | Bedeutung | Was zu ändern ist | | --- | --- | --- | | `too_many_filters` | Die Anfrage enthält mehr benannte Filter oder Data Slices, als eine Anfrage haben darf. | Verwenden Sie pro Anfrage weniger benannte Filter (oder Data Slices) dieses Typs. | | `empty_filter` | Ein Filter hat keine Adresse, und ein leerer Filter bedeutet alles. | Geben Sie jedem Filter mindestens eine Adresse an (Accounts: ein Account oder Owner; Transaktionen: eine Account-Liste). Shared gRPC bedient keinen leeren Filter. | | `too_many_addresses` | Ein Filterfeld listet zu viele Adressen auf. | Verwenden Sie weniger Adressen in einem Filterfeld; verteilen Sie sie auf mehrere Filter oder grenzen Sie die Liste ein. | | `address_not_allowed` | Ein Filter nennt eine Adresse, die Shared gRPC nicht zulässt. | Entfernen Sie diese Adresse mit hohem Volumen aus dem Filter. | | `filter_name_too_long` | Ein Filtername ist zu lang. | Verwenden Sie kürzere Filternamen (die Map-Schlüssel). | | `invalid_commitment` | Die Commitment-Stufe ist nicht gültig. | Verwenden Sie `processed`, `confirmed` oder `finalized`. | | `invalid_address` | Ein Filter enthält eine ungültige Adresse. | Jede Adresse muss eine gültige base58-Solana-Adresse sein (keine leeren Strings, Leerzeichen oder falsche Länge). | | `invalid_signature` | Der Wert der Transaktionssignatur ist nicht gültig. | Verwenden Sie eine gültige base58-Transaktionssignatur. | | `invalid_account_data_filter` | Ein Daten-Filter für Accounts ist nicht gültig. | Korrigieren Sie die Filter für `memcmp`, `datasize` und Token-Account-Daten und halten Sie deren Anzahl innerhalb des in der Meldung genannten Limits. | | `invalid_data_slice` | Die Data Slices sind nicht gültig. | Sortieren Sie die Data Slices nach Offset und halten Sie sie überlappungsfrei. | | `blocks_include_not_allowed` | Die Optionen der blocks-Subscription sind auf Shared gRPC nicht verfügbar. | Lassen Sie `blocks` weg und nutzen Sie stattdessen eine Transaktions- oder `blocks_meta`-Subscription. | | `invalid_token_accounts_mode` | Der Token-Accounts-Modus ist nicht gültig. | Verwenden Sie `ALL` (0) oder `BALANCE_CHANGED` (1). | | `invalid_argument` | Keiner der obigen Gründe trifft zu. | Prüfen Sie Filter und Parameter der Anfrage, bevor Sie es erneut versuchen. | ## Q. Was bedeutet `ERPC_GRPC_REQUEST_FAILED`, wenn gRPC einen anderen Status ungleich null liefert? Die Anfrage ist mit einem gültigen gRPC-Status fehlgeschlagen, der den nächsten Schritt bestimmt. Reparieren Sie zum Beispiel eine Anfrage mit `OutOfRange (11)`, wenn ein historischer Bereich ungültig ist; verwenden Sie Backoff bei einem Verfügbarkeitsstatus wie `Unavailable (14)`. Stufen Sie nicht jeden Status ungleich null als vorübergehend ein und wiederholen Sie nicht jede Antwort unverändert. ## 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. Kann ich einen bestimmten Endpunkt verwenden? Um eine Umgebung mit niedriger Latenz aufrechtzuerhalten, wählt unser System automatisch den nächstgelegenen verfügbaren Knoten aus. Wenn Sie einen bestimmten Endpunkt nutzen möchten, empfehlen wir, einen Server zu mieten, der möglichst nah an diesem Endpunkt steht. ## Q. Ich bekomme einen 401-Fehler. Warum? Um eine Umgebung mit niedriger Latenz aufrechtzuerhalten, setzen wir IP-Beschränkungen ein. Wenn Sie kein Abonnement haben oder Ihre IP nicht registriert ist, erhalten Sie einen 401-Fehler. Bitte prüfen Sie, ob Ihre registrierte IP mit der IP übereinstimmt, von der Sie aktuell zugreifen. ## Q. Ich bekomme einen 429-Fehler. Warum? Sie haben das Verbindungslimit Ihres Plans erreicht. Wenn dieser Fehler auftritt, sollten Sie ein Upgrade Ihres Plans in Betracht ziehen. Wenn Sie mehr Verbindungen benötigen, als unser Premium-Plan bietet, wäre ein dedizierter gRPC-Knoten besser geeignet. ## 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. Wird der Verkaufspreis erhöht, nachdem ich abonniert habe? Solange Ihr Abonnement aktiv bleibt, gilt weiterhin der Verkaufspreis, den Sie sich bei der Anmeldung gesichert haben. Umgebungen, die Solanas Echtzeit-Workload standhalten, sind weltweit knapp, und wir planen, die Preise im Einklang mit der wachsenden Nachfrage nach Hardware und Netzwerk schrittweise anzuheben. Höher spezifizierte Konfigurationen und stark nachgefragte Regionen sind am schnellsten ausverkauft; sich den aktuellen Preis zu sichern, ist daher langfristig die kosteneffizienteste Wahl. ## Q. Ich möchte mit Krypto bezahlen Krypto-Zahlungen sind im ERPC Web Dashboard verfügbar, wenn das Land Ihrer registrierten Rechnungsadresse eines der EU-Mitgliedsländer ist. Wenn alle in Ihrem Konto hinterlegten Zahlungskarten außerhalb der EU ausgestellt wurden, sind Krypto-Zahlungen nicht verfügbar. Sie können mit SOL, USDC oder EURC ERPC Credits kaufen. Mit diesen ERPC Credits können Sie ERPC-Pläne starten oder fortsetzen. Öffnen Sie das Dashboard, wählen Sie die Krypto-Zahlung, senden Sie die Zahlung aus Ihrer Wallet, und das Dashboard prüft die Transaktion und schreibt die Credits Ihrem Konto gut. Unterstützte Länder: Belgien, Bulgarien, Dänemark, Deutschland, Estland, Finnland, Frankreich, Griechenland, Irland, Italien, Kroatien, Lettland, Litauen, Luxemburg, Malta, Niederlande, Österreich, Polen, Portugal, Rumänien, Schweden, Slowakei, Slowenien, Spanien, Tschechien, Ungarn, Zypern. Für Länder, die nicht auf der Liste stehen, zahlen Sie bitte per Kreditkarte. [ERPC Web Dashboard](https://dashboard.erpc.global/de) ## Q. Wie kann ich die niedrigstmögliche Latenz erreichen? Wir empfehlen dringend, einen dedizierten gRPC-Knoten mit unserem [Bare-Metal-Server](https://erpc.global/de/baremetal/) zu kombinieren. Beide befinden sich im selben Netzwerk, was private Null-Distanz-Kommunikation ermöglicht, ohne das Internet zu durchqueren. Mit diesem Setup erreichen Sie eine extrem niedrige Latenz, typischerweise einen Ping von etwa 0,1 ms. Für weitere Details kontaktieren Sie uns bitte über das ERPC Web Dashboard. [ERPC Web Dashboard](https://dashboard.erpc.global/de) 🔗 [ERPC Web Dashboard](https://dashboard.erpc.global/de) ## 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. Wir bieten einfach zu bedienende Werkzeuge in TypeScript und Rust zur Messung der Latenz. - [Solana Stream SDK - ValidatorsDAO GitHub](https://github.com/ValidatorsDAO/solana-stream) - [SLV (Deutsch)](https://slv.dev/de) ## 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) ## 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. Ich habe eine hohe Latenz. Was kann ich tun? Die Latenz hängt stark davon ab, wie nah Sie sich am Endpunkt befinden. Wir empfehlen, von einem Server in der Nähe des bereitgestellten Endpunkts aus zuzugreifen. Die schnellsten Verbindungen erreichen Sie mit unserem [Bare-Metal-Server](https://erpc.global/de/baremetal/) und unserem [VPS-Dienst](https://erpc.global/de/vps/). ## Q. Was ist am schnellsten: WebSockets, gRPC oder Shreds? Das Feedback unserer Kunden ergibt durchgängig folgende Rangfolge der Geschwindigkeit: **Shreds > gRPC > WebSockets** Wenn Sie abweichende Ergebnisse beobachten, teilen Sie uns Ihre Erfahrungen bitte mit. ## Q. Die Latenz entspricht nicht meinen Erwartungen. Die Leistung variiert je nach verwendeter Programmiersprache. Im Allgemeinen ergibt sich folgende Rangfolge der Sprachgeschwindigkeit: **Rust > Go > TypeScript (JavaScript) > Python** Detaillierte Vergleiche finden Sie hier: [Geschwindigkeitsvergleich von Programmiersprachen](https://niklas-heer.github.io/speed-comparison/) Für maximale Leistung empfehlen wir dringend den Einsatz von Rust.