---
title: "Geyser gRPC - Meilleures pratiques"
description: "Conseils essentiels pour des clients Geyser gRPC de niveau production : ping/pong, reconnexion et filtres. Solana Stream SDK prend en charge Geyser gRPC."
canonical: "https://erpc.global/fr/doc/geyser-grpc/best-practices/"
locale: "fr"
---

# Geyser gRPC - Meilleures pratiques

Ce guide présente les modèles essentiels pour créer avec Geyser gRPC des applications robustes et prêtes pour la production. Solana Stream SDK prend en charge Geyser gRPC.

## Pour commencer

- Commencez simplement : démarrez avec des abonnements aux slots pour vous familiariser avec le streaming avant d'ajouter des filtres complexes.  
- Utilisez les filtres à bon escient : abonnez-vous uniquement à ce dont vous avez besoin pour réduire la bande passante et la charge CPU.

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

## Gestion des connexions

- Reconnexion automatique : attendez-vous à des problèmes réseau ; reconnectez-vous avec un backoff exponentiel.  
- Gestion du ping/pong : les serveurs Yellowstone gRPC envoient des pings. Répondez toujours par un pong, sinon le serveur peut fermer la connexion (cause fréquente des déconnexions au bout d'environ 30 s).  

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

- Récupération des données manquantes : utilisez `from_slot` après la reconnexion pour éviter de perdre des données (les doublons sont acceptables).

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

## Modèles d'architecture

- Séparez la réception et le traitement avec des canaux, pour découpler les E/S réseau de la logique métier et ajouter de la contre-pression.

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

- Utilisez des canaux bornés : choisissez la capacité selon la vitesse de traitement et la tolérance à la perte de données (plus petite = moins de mémoire, plus de pertes ; plus grande = plus de mémoire, moins de pertes).

## Performance et résilience

- Surveillez la latence de traitement et journalisez les dépassements de seuil.  
- Regroupez les écritures en base ; videz le lot selon sa taille ou un intervalle.  
- Utilisez des E/S asynchrones pour les appels externes ; déportez les calculs lourds vers des tâches ou threads de travail.  
- Réutilisez les requêtes d'abonnement pour réduire les allocations.

## Gestion des erreurs

- Distinguez les types d'erreur (stream, traitement, canal).  
- Corrigez une requête invalide avant de la réessayer ; n'utilisez un backoff exponentiel tenant compte des pauses que lorsqu'une réponse demande un nouvel essai.
- Journalisez les mises à jour abandonnées ou suivez-les par des métriques pour repérer les consommateurs trop lents.

## Corriger avant de réessayer et backoff tenant compte des pauses

Conservez la première erreur gRPC avant qu'une boucle de reconnexion ne la remplace. Notez son statut et son message, ainsi que les métadonnées présentes `x-erpc-error-code`, `x-erpc-error-reason`, `x-erpc-doc-url`, `x-erpc-retry-after-seconds` et `x-erpc-retry-at`. Une fermeture précoce de la connexion peut ressembler à une erreur de transport générique ; elle ne contient donc pas forcément tous les trailers.

Corrigez une requête invalide, une forme de filtre rejetée ou un écart d'enregistrement IP avant de réessayer. Lors d'une pause ERPC, attendez l'échéance renvoyée : elle est plus précise qu'un backoff local. Utilisez un backoff exponentiel borné pour les défaillances de disponibilité et les autres réponses qui autorisent un nouvel essai. Ne relancez pas sans cesse une requête inchangée au seul motif qu'elle a renvoyé un statut non nul.

## Utilisation des ressources et capacité de traitement

Les protections de l'environnement Shared empêchent qu'une charge de travail consomme la capacité de livraison nécessaire aux autres clients ERPC. Un stream peut devenir lent à cause de la bande passante effective, du CPU, de la mémoire, de la file du consommateur, des écritures en base ou d'appels externes. Les ressources doivent être à la hauteur de la charge ; un récepteur lent n'indique pas à lui seul quelle partie est limitante.

Mesurez le débit de pointe au niveau du consommateur. Convertissez les MB/s en Mbps avec `MB/s × 8`, puis gardez une marge au-dessus du pic mesuré. Il n'existe pas de minimum fixe valable sans mesure. Gardez le travail de réception court, transmettez les mises à jour à une file bornée, et augmentez les ressources ou réduisez l'abonnement si le traitement ne suit pas. Une file bornée limite l'utilisation de la mémoire ; elle ne peut pas résoudre un consommateur durablement lent.

## Gestion des données

- Gérez les doublons lors de l'utilisation de `from_slot` (cache limité dans le temps ou contraintes en base).  
- Choisissez le niveau de commitment selon le cas d'usage :  
  - processed : dashboards les plus rapides, peut faire l'objet d'un rollback  
  - confirmed : bon choix par défaut pour la plupart des applications et indexeurs  
  - finalized : lorsqu'une certitude absolue est requise

## Abonnements dynamiques

Utilisez le stream bidirectionnel pour mettre à jour les abonnements pendant l'exécution (remplacement de filtres à chaud, extension de la couverture) sans vous reconnecter.

## Liste de contrôle pour la production

- ✅ Reconnexion automatique avec backoff exponentiel  
- ✅ Récupération des données manquantes avec `from_slot`  
- ✅ Gestion du ping/pong (éviter les déconnexions à 30 s)  
- ✅ Séparation de la réception et du traitement avec des canaux bornés / de la contre-pression  
- ✅ Journalisation des erreurs et métriques/alertes  
- ✅ Suivi de la latence de traitement  
- ✅ Gestion des doublons et optimisation des filtres  
- ✅ Écritures par lots (en cas de persistance)  
- ✅ Arrêt propre et contrôles de santé

## Ressources supplémentaires

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