--- title: "FAQ - Latence et régions" description: "Foire aux questions sur la latence et les régions d'ERPC, en deux parties: questions non propres à une chaîne, puis réponses liées au fonctionnement de Solana." canonical: "https://erpc.global/fr/faq/latency/general/" locale: "fr" --- # FAQ - Latence et régions Les questions sur la facturation, le forfait Gratuit, le paiement et les erreurs 401 ou 429 se trouvent dans [Comment démarrer](https://erpc.global/fr/faq/how-to-start/general/). ## Non spécifique à une chaîne Ces questions portent sur l'effet de la distance, de la région, de l'emplacement des serveurs, des endpoints partagés ou dédiés et du langage de votre client sur la latence. ### Q. Dois-je choisir une région? Avec [Edge RPC](https://erpc.global/fr/doc/rpc/edge/), vous n'avez pas besoin de choisir une région. Une application qui se connecte à edge.erpc.global est acheminée automatiquement vers un point d'entrée proche sur le chemin réseau. Avec Unlimited Endpoints pour Solana, Ethereum et Avalanche C-Chain, vous choisissez la région lors de la commande, à proximité de l'endroit où tourne votre système de trading ou votre backend. Vérifiez les régions disponibles dans l'[ERPC Web Dashboard](https://dashboard.erpc.global/fr) lors de la commande. Sur Solana, aucune région ne convient à toutes les stratégies, car le rôle de leader passe d'un validateur à l'autre selon le planning des leaders; voir la section Solana ci-dessous. ### Q. J'ai une latence élevée. Pourquoi? Accédez-vous à l'endpoint depuis un emplacement physiquement proche? La distance a un impact important sur la latence. Nous vous recommandons d'y accéder depuis des serveurs proches de l'endpoint fourni. Notre réseau offre en théorie les connexions les plus rapides grâce à nos [serveurs bare metal](https://erpc.global/fr/baremetal/) et à nos [services VPS](https://erpc.global/fr/vps/). ### Q. Qu'en est-il de la latence? La latence varie selon la méthode de mesure et votre environnement d'utilisation spécifique. Plutôt que de se concentrer sur des valeurs numériques exactes, il est crucial de s'assurer que la latence répond à vos besoins opérationnels réels. Pour Solana, vous pouvez mesurer la latence avec ces outils open source pour TypeScript et Rust. - [Solana Stream SDK - ValidatorsDAO GitHub](https://github.com/ValidatorsDAO/solana-stream) - [SLV (français)](https://slv.dev/fr) ### Q. Pourquoi les endpoints dédiés sont-ils plus rapides? Les endpoints partagés sont utilisés par plusieurs clients qui se partagent les mêmes ressources. Lorsque le trafic augmente, de la latence a tendance à apparaître. Les ressources serveur ont des limites physiques, et la quantité de travail qu'elles peuvent traiter est finie. Lorsque trop de requêtes arrivent en même temps, elles doivent être traitées l'une après l'autre, ce qui ralentit les temps de réponse. Même si nous prenons diverses mesures pour optimiser les performances, y compris sur les endpoints partagés, avec un endpoint dédié vous êtes l'unique utilisateur de la ressource. Vous n'êtes donc aucunement affecté par les autres utilisateurs, ce qui garantit des réponses toujours stables et rapides. Les endpoints dédiés offrent aussi des options de communication sans TLS, comme HTTP. En évitant le handshake TLS (environ 20 ms), la communication devient encore plus rapide qu'en HTTPS. ### Q. Quel plan est le plus rapide? En général, notre plan le plus haut de gamme offre les meilleures performances grâce à des CPU plus puissants, davantage de mémoire et des configurations matérielles plus robustes. Nous proposons aussi des solutions personnalisées si vous avez besoin de serveurs encore plus puissants, mais nos plans standard sont conçus pour offrir un rapport prix/performance optimal. Nous sommes convaincus d'offrir des performances de classe mondiale à chaque niveau de prix. Si vous trouvez un fournisseur plus rapide dans la même gamme de prix, merci de nous le signaler afin que nous puissions analyser la situation et apporter des améliorations. ### Q. La latence ne correspond pas à mes attentes. Les performances peuvent varier considérablement selon le langage de programmation utilisé. En général, les comparaisons de vitesse entre langages donnent le classement suivant: **Rust > Go > TypeScript (JavaScript) > Python** Pour des comparaisons plus détaillées, consultez la ressource suivante: [Comparaison de vitesse par langage de programmation](https://niklas-heer.github.io/speed-comparison/) Nous vous recommandons vivement d'utiliser Rust si votre objectif est d'obtenir des performances maximales. ## Solana Ces réponses reposent sur le fonctionnement de Solana: le rôle de leader passe d'un validateur à l'autre selon le planning des leaders, si bien que l'emplacement des validateurs oriente le choix de votre région. ### Q. Quelle région recommandez-vous? Il n'existe pas de région qui soit la meilleure en permanence. Solana est un réseau mondial, et le rôle de leader passe d'un validateur à l'autre selon le planning des leaders. Les régions avec davantage de validateurs et un stake plus élevé obtiennent plus souvent des slots leaders, ce qui peut aider les transactions à être confirmées plus vite. En contrepartie, le trafic concurrent s'y concentre aussi; une région moins saturée peut donc parfois donner de meilleurs résultats selon votre stratégie. Comme point de départ, choisissez une région dense en validateurs, comme Francfort ou la côte Est des États-Unis, lorsque la disponibilité régulière de slots leaders compte le plus. Placez-vous plutôt près d'un validateur cible précis lorsque l'exécution par le chemin le plus court est prioritaire. Utilisez [Validators Solutions](https://validators.solutions/) pour comprendre la distribution publique du réseau Solana, puis l'[ERPC Leader Slot API](https://erpc.global/fr/doc/rpc/leader-slot-api/) et des mesures réelles pour décider si un déploiement mono-région, bi-région ou global est approprié. [![Rapport sur la distribution du mainnet Solana](https://erpc.global/faq/SolanaMainnetReportEN.jpg)](https://validators.solutions/) ### Q. J'ai besoin d'une latence d'environ 400 ms ou moins. Pour atteindre une latence d'environ 400 ms ou moins, tenez compte de ces points essentiels: - **Compréhension réaliste des valeurs du ping**: Les valeurs de ping indiquent des conditions idéales et ne reflètent pas la latence réelle des communications en streaming, qui est généralement de l'ordre de cinq fois la latence du ping. Par exemple, un ping de 100 ms entre continents se traduit en pratique par environ 500 ms de latence. Ainsi, des infrastructures doivent être mises en place dans la même région pour atteindre ~400 ms de latence. - Références typiques de ping: - Même réseau: ~0,1 ms - Interconnexion réseau privée (PNI): ~0,2 ms - Même centre de données: ~0,3 ms - Même ville: ~1 ms - Pays voisin: ~5–10 ms - Intercontinental: ~100–300 ms - **Éviter le piège de la latence moyenne**: Les validateurs de Solana sont dispersés géographiquement à l'échelle mondiale, et le planning des leaders change de façon aléatoire à chaque époque. Il n'est pas réaliste de s'appuyer sur la latence moyenne pour atteindre ~400 ms. Au lieu de cela, vous devriez suivre précisément les plannings des validateurs dans votre région spécifique pour identifier les slots avec la latence la plus basse. Pour obtenir une latence minimale de façon constante, il faut une infrastructure dans toutes les régions concernées. Dans la même région, l'acquisition de données peut se faire en dizaines de millisecondes, la transmission étant possible en quelques millisecondes seulement. - **Suivi du planning des leaders**: Surveillez le planning des validateurs leaders de votre région avec l'**ERPC Leader Slot API (`getLeaderSlots`)**. Elle renvoie le planning des prochains leaders, le poids de stake de l'époque en cours, la géolocalisation estimée des validateurs et des valeurs de ping de référence, pour que vous puissiez identifier les slots offrant la latence la plus faible et les cibler avant qu'ils n'arrivent. Les données publiques de type carte et les API RPC natives sont utiles pour obtenir une vue d'ensemble du réseau, mais elles ne sont pas assez précises pour le timing d'exécution. La Leader Slot API comble cette lacune avec la granularité nécessaire pour le routage et les décisions de trading. - [Documentation de l'ERPC Leader Slot API](https://erpc.global/fr/doc/rpc/leader-slot-api/) - [ERPC Web Dashboard](https://dashboard.erpc.global/fr) [![Validators Solutions - Données du réseau Solana](https://erpc.global/faq/ValidatorsSolutionsEN.jpg)](https://validators.solutions/) Données du réseau Solana: [Validators Solutions](https://validators.solutions/) ### Q. Comment puis-je réaliser le trading zero-block (zero-slot)? Réussir le trading zero-block (zero-slot) nécessite des stratégies plus sophistiquées, comme suit: - **Identification des zones d'opportunité**: Les validateurs Solana sont répartis dans le monde entier, et il est physiquement impossible d'obtenir une latence optimale sur chaque slot. Par conséquent, surveillez les plannings des validateurs leaders dans la région où se trouve votre infrastructure et identifiez les zones d'opportunité les plus favorables. Le déploiement d'infrastructures dans plusieurs régions peut également être avantageux. Par exemple, Francfort est une région clé en raison de sa forte densité de validateurs, ce qui entraîne une sélection plus fréquente des leaders et de meilleures opportunités de trading. Utilisez l'**ERPC Leader Slot API (`getLeaderSlots`)** pour consulter le planning des prochains leaders, le poids de stake de l'époque en cours, des données de géolocalisation estimée des validateurs et des valeurs de ping de référence, avec une précision bien supérieure à celle des sources de données publiques de type carte ou des API RPC natives. Vous pouvez ainsi cartographier les zones d'opportunité avant l'arrivée des slots et exécuter des trades à latence quasi nulle. - [Documentation de l'ERPC Leader Slot API](https://erpc.global/fr/doc/rpc/leader-slot-api/) - [ERPC Web Dashboard](https://dashboard.erpc.global/fr) - **Mise en œuvre des nœuds dédiés**: Si vous avez du mal à rivaliser, envisagez de déployer des nœuds dédiés. Les nœuds partagés subissent la latence générée par le trafic d'autres utilisateurs et ne sont donc pas recommandés. De plus, placer votre nœud dédié dans le même réseau que votre application réduit considérablement la latence du réseau et optimise les performances. ### Q. Quel est le plus rapide: WebSockets, gRPC ou Shreds? Les retours de nombreux clients sont assez cohérents, et l'ordre de performance est le suivant: **Shreds > gRPC > WebSockets** Si vous constatez des résultats ou des conditions différents, merci de nous en informer. ### Q. Ce RPC (gRPC, Shreds) est-il plus rapide que les autres? Nous concevons chaque niveau d'offre pour la vitesse, et nous sommes heureux d'être comparés côte à côte avec n'importe quel autre fournisseur. Les résultats peuvent varier selon la région, selon que vous utilisez un endpoint partagé ou dédié, selon le protocole (WebSockets, gRPC ou Shreds) et selon le langage de programmation de votre client. Si notre service vous semble plus lent, indiquez-nous via l'ERPC Web Dashboard les conditions précises et les concurrents auxquels vous l'avez comparé. Nous en identifierons la cause et améliorerons encore la vitesse. [ERPC Web Dashboard](https://dashboard.erpc.global/fr)