---
title: "Geyser gRPC - Best Practices"
description: "Wesentliche Tipps für produktionsfähige Geyser gRPC-Clients, einschließlich Ping/Pong, Wiederverbindung und Filter. Solana Stream SDK unterstützt Geyser gRPC."
canonical: "https://erpc.global/de/doc/geyser-grpc/best-practices/"
locale: "de"
---

# Geyser gRPC - Best Practices

Diese Anleitung umfasst wesentliche Muster für den Aufbau robuster, produktionsbereiter Anwendungen mit Geyser gRPC. Solana Stream SDK unterstützt Geyser gRPC.

## Erste Schritte

- Starten Sie einfach: Beginnen Sie mit Slot-Abonnements, um sich mit Streaming vertraut zu machen, bevor Sie komplexe Filter hinzufügen.  
- Verwenden Sie Filter sinnvoll: Abonnieren Sie nur, was Sie benötigen, um Bandbreite und CPU-Last zu reduzieren.

```rust
SubscribeRequestFilterTransactions {
    vote: Some(false),   // Exclude vote txs
    failed: Some(false), // Exclude failed txs
    ..Default::default()
}
```

## Verbindungsmanagement

- Automatische Wiederverbindung: Rechnen Sie mit Netzwerkproblemen und verbinden Sie sich mit exponentiellem Backoff neu.  
- Ping/Pong-Handling: Yellowstone-gRPC-Server senden Pings. Antworten Sie immer mit Pong, andernfalls kann der Server die Verbindung schließen (häufige Ursache von ~30-Sekunden-Trennungen).  

```rust
if matches!(update.update_oneof, Some(UpdateOneof::Ping(_))) {
    subscribe_tx.send(SubscribeRequest {
        ping: Some(SubscribeRequestPing { id: 1 }),
        ..Default::default()
    }).await?;
}
```

- Gap-Recovery: Verwenden Sie nach dem Wiederverbinden `from_slot`, um Datenverlust zu vermeiden (Duplikate sind akzeptabel).

```rust
subscribe_request.from_slot = if tracked_slot > 0 {
    Some(tracked_slot) // Optionally subtract a small buffer to dodge reorgs
} else {
    None
};
```

## Architekturmuster

- Trennen Sie Ingress und Verarbeitung mit Kanälen, um das Netzwerk-I/O von der Geschäftslogik zu entkoppeln und Backpressure einzubauen.

```rust
let (tx, rx) = mpsc::channel::<SubscribeUpdate>(10_000);
// ingress task reads stream and tx.send(...)
// processing task consumes rx and does business logic
```

- Verwenden Sie begrenzte Kanäle: Wählen Sie die Kapazität basierend auf Verarbeitungsgeschwindigkeit und Datenverlusttoleranz (kleiner = weniger Speicher, mehr verworfene Updates; größer = mehr Speicher, weniger verworfene Updates).

## Leistung und Widerstandsfähigkeit

- Überwachen Sie die Verarbeitungslatenz und loggen Sie Überschreitungen von Schwellenwerten.  
- DB-Schreibvorgänge bündeln; nach Batchgröße oder Intervall flushen.  
- Verwenden Sie asynchrones I/O für externe Aufrufe; lagern Sie rechenintensive Berechnungen in Worker-Tasks/-Threads aus.  
- Subscription-Requests wiederverwenden, um Allokationen zu reduzieren.

## Fehlerbehandlung

- Fehlertypen unterscheiden (Stream vs. Verarbeitung vs. Kanal).  
- Ungültige Anfragen vor dem Wiederholen reparieren; pausensensiblen exponentiellen Backoff nur verwenden, wenn eine Antwort ein Wiederholen vorsieht.
- Verworfene Updates in Logs/Metriken erfassen, um Situationen mit langsamen Verbrauchern zu erkennen.

## Vor dem Wiederholen reparieren und pausensensibler Backoff

Bewahren Sie den ersten gRPC-Fehler auf, bevor eine Reconnect-Schleife ihn ersetzt. Notieren Sie Status und Meldung sowie vorhandene Metadaten `x-erpc-error-code`, `x-erpc-error-reason`, `x-erpc-doc-url`, `x-erpc-retry-after-seconds` und `x-erpc-retry-at`. Ein frühes Verbindungsende kann wie ein allgemeiner Transportfehler aussehen und daher nicht jeden Trailer enthalten.

Reparieren Sie eine ungültige Anfrage, abgelehnte Filterform oder IP-Registrierungsabweichung vor dem Wiederholen. Warten Sie bei einer ERPC-Pause bis zur zurückgegebenen Frist; sie ist spezifischer als lokaler Backoff. Verwenden Sie begrenzten exponentiellen Backoff bei Verfügbarkeitsfehlern und anderen wiederholbaren Antworten. Wiederholen Sie eine unveränderte Anfrage nicht allein deshalb, weil sie einen Status ungleich null zurückgab.

## Ressourcenverbrauch und Verarbeitungskapazität

Die Schutzmechanismen der Shared-Umgebung verhindern, dass ein einzelner Workload Zustellkapazität verbraucht, die andere ERPC-Kunden benötigen. Ein Stream kann durch effektive Bandbreite, CPU, Speicher, die Consumer-Queue, Datenbankschreibvorgänge oder externe Aufrufe langsam werden. Ausreichende Ressourcen müssen zur Last passen; ein langsamer Empfänger allein zeigt noch nicht, welcher Teil der Engpass ist.

Messen Sie die Datenrate am Verbraucher zur Spitzenzeit. Rechnen Sie MB/s mit `MB/s × 8` in Mbps um und lassen Sie über dem gemessenen Maximum Spielraum. Es gibt kein festes ungemessenes Minimum. Halten Sie Empfangsarbeit kurz, übergeben Sie Updates an eine begrenzte Queue und skalieren oder reduzieren Sie die Subscription, wenn die Verarbeitung nicht nachkommt. Eine begrenzte Queue begrenzt den Speicher, kann aber keinen dauerhaft langsamen Verbraucher beheben.

## Datenverwaltung

- Duplikate bei Verwendung von `from_slot` behandeln (zeitlich begrenzter Cache oder DB-Constraints).  
- Commitment je nach Anwendungsfall wählen:  
  - processed: schnellste Dashboards, kann zurückrollen  
  - confirmed: guter Standard für die meisten Apps/Indexer  
  - finalized: wenn maximale Sicherheit erforderlich ist

## Dynamische Abonnements

Verwenden Sie den bidirektionalen Stream, um Abonnements zur Laufzeit zu aktualisieren (Hot-Swap-Filter, erweiterte Abdeckung) ohne erneute Verbindung.

## Produktionsprüfliste

- ✅ Automatische Wiederverbindung mit exponentiellem Backoff  
- ✅ Gap-Recovery mit `from_slot`  
- ✅ Ping/Pong-Handling (verhindert 30-Sekunden-Trennungen)  
- ✅ Ingress und Verarbeitung mit begrenzten Kanälen/Backpressure trennen  
- ✅ Fehlerprotokollierung und Metriken/Alerting  
- ✅ Verfolgung der Verarbeitungslatenz  
- ✅ Duplikatbehandlung und Filteroptimierung  
- ✅ Batch-Schreibvorgänge (bei Persistenz)  
- ✅ Graceful Shutdown und Health Checks

## Weitere Ressourcen

- Solana Stream SDK (Geyser gRPC-Unterstützung): https://github.com/ValidatorsDAO/solana-stream