Pourquoi mon application Solana est-elle lente? Pourquoi la distance réseau compte

Nous entendons souvent des commerçants et des constructeurs:

Je lance une stratégie similaire, mais seul mon bot est rempli tard.
Les prix mettent à jour bien, mais mes transactions ne le font pas à temps.
C'est changé RPC fournisseurs, mais la performance ne change pas vraiment.

Les premiers suspects dans ces situations sont généralement:

Mon code doit être lent.
Mes spécifications de serveur ne sont probablement pas assez bonnes.

Ces deux-là peuvent avoir beaucoup d'importance. Mais dans un environnement à grande vitesse comme Solana, il y a un goulot d'étranglement encore plus fondamental qui apparaît souvent en premier: la distance réseau.

Sur Solana, il y a d'innombrables dApps, DeFi les protocoles, et les marchés fonctionnant sur la chaîne, et beaucoup d'entre eux comptent sur le trading automatisé à travers les robots. Dans ce qui est effectivement un environnement de trading à haute fréquence (HFT), être capable de détecter les événements plus rapidement et exécuter plus rapidement que vos concurrents vous donne un avantage et un moyen de capturer le profit.

Dans cet article, nous examinerons pourquoi la distance réseau devient un facteur décisif lorsque vous visez la détection rapide et l'exécution à faible latence sur Solana, et comment les bundles ERPC et offres VPS sont conçues pour répondre à ces besoins.

Pourquoi a-t-on l'impression que seule mon application est lente?

Tout d'abord, les laissez organiser quelques situations communes:

Votre serveur a beaucoup de CPU et de mémoire, mais vos réactions commerciales sont encore plus lentes que la concurrence.
Vous voyez de nouveaux événements via getProgramAccounts ou des abonnements log, mais vos soumissions de transaction sont toujours à un demi-pas derrière.
Vous avez essayé plusieurs environnements nuageux et plusieurs RPC Mais rien ne semble être une percée.

Dans ces situations, de nombreux développeurs essaient de tirer plus de performances de leur code ou algorithmes. C'est un effort valable et important, mais il y a une question structurelle plus profonde qui peut rester sans solution:

Vous pourriez vous battre à partir d'un réseau lointain.
Du point de vue du validateur de leader, votre candidature pourrait être située dans une position physiquement désavantagée.

Si ces conditions tiennent, peu importe combien vous raffinez votre logiciel, vous n'atteindrez jamais pleinement le niveau de performance que vous visez.

Pour vraiment profiter de la vitesse de Solana, vous devez considérer trois couches ensemble:

Code
Matériel
Réseau

Parmi ceux-ci, la première place que vous devriez souvent entendre est la distance réseau.

Trois couches qui déterminent la vitesse

Code (logiciel et stratégie)

Pour les robots et les systèmes de style HFT sur Solana, votre code et votre stratégie affectent directement vos résultats:

Quels événements vous utilisez comme déclencheurs
Dans quelles conditions entrez et sortez-vous
Combien inutile/O vous supprimez, et à quel point vous parallélisez le traitement

Ce sont les leviers d'optimisation les plus intuitifs pour de nombreux développeurs. Les améliorations au niveau du code sont essentielles, mais elles ne sont qu'une pièce du puzzle.

Matériel

Le prochain facteur majeur est la performance du serveur. Avoir une capacité suffisante n'est pas suffisant. Vous devez regarder:

CPU à haute vitesse (comment un seul noyau peut traiter les tâches)
Compte de base (combien de tâches peuvent fonctionner en parallèle)
Capacité de mémoire et nombre de canaux de mémoire (qu'il soit possible d'accéder aux grands ensembles de travail sans décrochage)
Stockage rapide tel que NVMe (de sorte que l'enregistrement et les écritures de données ne deviennent pas un goulot d'étranglement)

La charge de travail des tradings nécessite souvent la gestion d'index importants et l'état. Dans ce contexte:

Grands caches CPU
Ample RAM sans risque d'échange

des performances plus stables.

Bien sûr, les environnements plus performants coûtent plus cher. En fin de compte, vous avez besoin d'un point d'équilibre où le bénéfice attendu de votre stratégie justifie l'investissement matériel.

Réseau

Le plus négligé, mais souvent le facteur le plus important pour la latence est le réseau.

Avec l'optimisation CPU, vous pourriez être raser des centaines de nanosecondes à quelques microsecondes. Avec l'optimisation du réseau, la différence que vous pouvez atteindre peut soudainement être dans la gamme de centaines de millisecondes. En termes de magnitude, les changements de réseau peuvent avoir mille fois plus d'impact.

Même si vous avez:

Un serveur puissant
Logiciels efficaces
Une stratégie bien conçue

mettre vos ressources dans le mauvais emplacement du réseau annulera une grande partie de l'effort. Le premier mouvement devrait être de choisir le bon centre de données et le bon réseau pour votre application.

Régulariser l'intuition sur la distance réseau

Parce que les réseaux ne sont pas visibles de la même manière que CPU ou RAM, il est difficile de construire l'intuition à leur sujet. Pour faciliter les choses, cela aide à penser en termes de transport.

Quand vous pensez à Internet, imaginez:

Votre serveur comme point de départ
Le validateur Solana ou RPC comme destination

et photo voyageant en voiture ou en avion entre ces points.

Voyages à courte distance:

Avoir moins de feux de circulation et d'intersections
Sont moins exposés à la congestion
Avoir peu de variation dans l'heure d'arrivée et généralement rester à l'horaire

Voyages à longue distance:

Exiger des autoroutes, des tunnels et des aéroports centraux
Passez par de nombreux points intermédiaires
Sont plus facilement touchés par la construction, les accidents ou les embouteillages

En conséquence, les temps d'arrivée varient beaucoup plus.

Les réseaux se comportent de la même manière:

Câbles en fibres plus courtes
Moins de routeurs et de commutateurs intermédiaires (intersections et moyeux)

signifie des temps aller-retour plus courts et moins de bruit.

La largeur de bande (1Gbps, 10Gbps, 25Gbps) est comme le nombre de voies sur une route. Davantage de voies permettent à plus de données de circuler en parallèle et de réduire la congestion. Mais même avec de nombreuses voies, si la route est trop longue ou indirecte, le temps total de déplacement sera encore important.

Sur Solana, si vous voulez une vraie vitesse, vous avez besoin des deux:

Assez de voies (bande passante)
Courte distance et itinéraires efficaces

Comment la structure de Solanas amplifie l'effet de la distance

Sur Solana, les blocs sont produits par des validateurs de leader qui tournent chaque slot, avec des leaders situés dans le monde entier.

Aujourd'hui, de nombreux validateurs sont regroupés dans des régions comme Francfort. Cependant, même ainsi, les leaders se déplacent:

Francfort
New York
Tokyo
Singapour

et d'autres régions du monde.

Dans cette structure:

Lorsqu'un leader est à Francfort, les nœuds à l'intérieur du réseau de Francfort présentent un avantage évident.
Quand un leader est à Tokyo, les nœuds près de Tokyo sont à un avantage.

C'est une réalité très simple mais très puissante.

La communication intercontinentale coûte généralement plus de 100 ms en aller-retour seul. Par exemple:

Chasser un leader de Tokyo de Francfort
Chasser un leader de New York de Tokyo

signifie que lorsque vous incluez la réception et le traitement du flux Shreds, votre délai de détection efficace peut facilement être retardé de 1000 ms ou plus. Pour le commerce et le suivi des applications, ce délai est énorme.

Pourquoi chasser la latence moyenne ne suffit pas

Les premières mesures que de nombreux utilisateurs regardent sont:

Ping moyen
Temps de réponse moyen

Ceux-ci sont utiles, mais sur un réseau comme Solana où les leaders se déplacent à travers le monde slot par slot, il y a une grande différence entre:

Avoir une bonne moyenne
Être rapide aux moments spécifiques où il importe

Même si une certaine configuration montre une latence moyenne de 200 ms, en réalité vous pourriez voir:

20 ms dans certaines slots
600 ms dans d'autres emplacements

Pour le trading de 0-slot ou toute stratégie qui repose sur être dans une fenêtre de 200 à 400 ms, ce qui importe n'est pas la moyenne:

C'est si vous pouvez opérer avec une faible latence
Au moment exact
Dans votre région cible

Chaque fois que vous essayez de frapper des leaders qui sont situés sur un autre continent, il y aura des créneaux où vous êtes physiquement incapable de suivre.

Si vous ne vous concentrez que sur la latence moyenne et ignorez cette réalité, vous resterez coincé dans la zone "Je ne sais pas pourquoi je perds".

Isolant où votre application est en fait lente

D'ici, voyons comment identifier où votre application perd du temps.

Mesurez votre latence actuelle

Tout d'abord, mesurez la distance à vos paramètres actuels en tant que nombres, pas en tant que sentiments.

Votre actuel RPC / gRPC / ShredStream paramètres
Nœuds situés dans la même région que ces paramètres

Exécuter des tests de ping contre eux et enregistrer le point de référence aller-retour.

Ne vous fiez pas à une seule mesure. Exécutez plusieurs pings à de courts intervalles et regardez la médiane plutôt que la moyenne. Cela donne une meilleure image de ce jour.

Séparer le temps réseau du temps de traitement de l'application

Dans votre application, enregistrez:

Demande d'envoi d'horodatage
Réponse recevoir des timestamps
Temps de début et de fin du traitement interne

Puis, séparer:

Combien de temps est consacré aux voyages aller-retour en réseau
Combien de temps est consacré à votre véritable logique d'affaires

Dans de nombreux cas, vous trouverez:

Votre code se termine en quelques millisecondes à quelques dizaines de millisecondes
Les voyages aller-retour en réseau consomment des centaines de millisecondes

Modèles typiques de goulot d'étranglement

Voici quelques exemples courants:

Utiliser la même endpoint RPC du monde entier
Connexion depuis la maison ou le bureau à travers plusieurs couches de VPN et de proxies
Hébergement de serveurs dans une seule région et tentative de chasser chaque leader dans le monde à partir de là

Dans ces configurations, la structure de Solanas garantit presque que vous serez toujours attaquer certains leaders à partir d'une position défavorisée.

Conception avec distance réseau de votre côté

Pour que la distance réseau fonctionne pour vous, plutôt que contre vous, il y a plusieurs étapes clés.

Décidez dans quel réseau vous vous battez

Pour Solana, le réseau qui vous intéresse est celui construit par des validateurs. La fréquence des créneaux de leader est proportionnelle à la quantité de stake, donc:

Réseaux qui hébergent des validateurs avec un enjeu important

devenir efficacement des réseaux primaires en pratique.

Commencez par comprendre:

Quelles régions sont proches des marchés ou des applications qui comptent pour votre stratégie
Comment envisagez-vous de couvrir les régions à enjeux importants comme Francfort

C'est ainsi que vous décidez quels réseaux vous voulez réellement combattre.

Centre de données et sélection du réseau

Pour les charges de travail de Solana, il est crucial de savoir si:

Vous êtes dans le même centre de données que les validateurs de clés ou Jito Moteur à blocage
Ou connecté à eux via PNI (Private Network Interconnect)

L'Internet est global, et en principe, votre application va --travailler - peu importe où vous l'avez mis. Toutefois, pour la détection HFT ou en temps quasi réel, les principales questions sont les suivantes:

Combien de trafic réseau externe pouvez-vous éliminer?
À quelle distance pouvez-vous accéder à une configuration à distance zéro?

Ces choix créent le premier écart de performance majeur.

Entrée dans les architectures multi-régions

Dans le monde idéal, vous seriez présent partout, mais vous n'avez pas besoin de couvrir toutes les régions dès le premier jour.

Une première étape pratique est quelque chose comme:

Francfort (grand réseau)
Plus une autre région qui est importante pour votre stratégie (New York, Tokyo, Singapour, etc.)

D'un petit nombre de régions, vous pouvez progressivement vous développer.

Dans chaque région, vous:

Recevoir les chreds et gRPC localement
Traitement complet localement, ou vers l'avant sur votre propre réseau via le chemin le plus court possible

Cela rend beaucoup plus facile de maintenir un état d'être le plus rapide quelque part à un moment donné.

La conception ERPC du réseau et comment Bundle / VPS S'adapter

Maintenant, laissez-nous cartographier les idées ci-dessus à La conception ERPC et la gamme de produits.

Réseaux axés sur Solana et architecture fondée sur l'INP

ERPC est construit comme un réseau spécialisé pour Solana. Nous sélectionnons soigneusement:

Régions où le stake sont concentrés
Centres de données qui hébergent les principaux validateurs et Jito Moteur à blocage
Centres de données qui sont directement connectés par l'intermédiaire du PNI à ces emplacements centraux

construire une topologie qui peut fournir une sortie maximale pour les charges de travail de Solana.

Internet est global, et votre application fonctionnera où que vous le déployiez. Mais lorsque vous vous souciez de HFT ou de détection rapide, vous devez d'abord obtenir la sélection du centre de données et la sélection du réseau correctement. ERPC est conçu spécifiquement pour traiter ce problème pour Solana.

Routage automatique basé sur le ping

Pour partage les endpoints Solana RPC, ERPC ne se fie pas à la géolocalisation IP. Nous:

Mesurer automatiquement ping de chaque région à chaque IP sur liste blanche
Choisissez la région la plus proche en fonction des mesures réelles

Cela évite des questions telles que:

Routes qui regardent de près sur une carte mais sont en fait de longs détours
Décisions d'acheminement fondées sur des bases de données géolocalisées désuètes

et vous assure toujours de vous connecter via le chemin le plus court que nous pouvons mesurer dans la pratique.

Solana RPC Plans d'ensemble

Les Solana RPC Les plans de groupe vous donnent:

RPC (HTTP/ WebSocket)
Geyser gRPC (aucune restriction de filtre)
ShredStream gRPC

dans un seul colis.

La plupart des équipes commencent leur voyage Solana en temps réel avec Geyser gRPC. Comme il fournit des données déjà décodées:

La mise en œuvre est plus simple
Il y a de nombreux exemples et références
La courbe d'apprentissage est relativement douce

Pendant ce temps, les équipes professionnelles ajoutent ShredStream pour pousser la détection et l'exécution plus près du bord d'attaque.

Avec le groupe:

Vous pouvez garder votre production existante RPC / gRPC configuration
Vous pouvez ajouter ShredStream sans coût supplémentaire important

Le prix est conçu pour vous permettre:

Construisez une application de base stable en utilisant RPC + gRPC
Puis, dans ce même environnement, commencer à expérimenter avec ShredStream et passer progressivement à des performances plus élevées

Tout cela sans arrêter vos systèmes de production.

EPYC VPS / Ryzen Premium VPS

Pour pousser encore plus loin la distance réseau, ERPC fournit également VPS offres dans le même réseau que Eles endpoints RPC.

La gamme comprend:

EPYC VPS pour un bon rapport coût-efficacité
Ryzen Premium VPS construit sur des processeurs Ryzen 5,7 GHz

Ces environnements fournissent:

CPU haute vitesse
CCE DDR5 mémoire
Stockage NVMe4
25 Gbps × 2 réseaux

Tous adaptés aux charges de travail de Solana.

Ces VPS instances exécutées dans le même réseau que:

Jito Moteur à blocage
ShredStream nœuds
nœuds Geyser gRPC

Cette configuration de distance zéro vous permet d'exécuter vos applications près des leaders sans traverser les réseaux externes.

En combinant les plans Bundle avec ceux-ci VPS offres, vous pouvez optimiser conjointement:

Distance réseau
Performance du matériel
Qualité des flux

et construire une base solide pour les cas d'utilisation sensibles à la latence.

Où commencer (liste de contrôle)

Voici les étapes que vous pouvez prendre juste après avoir terminé cet article:

Mesurer ping à votre courant RPC / gRPC / ShredStream paramètres Faire cela plusieurs fois sur une courte période et regarder la médiane, pas seulement un seul échantillon.
Ajouter la connexion dans votre application pour séparer le temps réseau du temps de traitement Mesurer la demande envoyer → réponse recevoir, et le traitement interne fait entre ces deux points.
Vérifier quelles régions sont réellement proches de vos marchés cibles ou dApps Si possible, mesurez ping de plusieurs régions candidates afin que vos décisions soient basées sur des données, pas seulement sur l'intuition.
Déployer un seul VPS ou Bundle dans une région proche de vos cibles clés et exécutez des tests de comparaison Enregistrez et comparez les améliorations de votre latence par rapport à votre environnement existant.
Élargir à une architecture multi-régions au besoin Par exemple: Francfort + New York, Francfort + Tokyo ou Francfort + Singapour, selon votre stratégie.
À plus long terme, recueillir des données sur les plannings des leaders et les lieux de validation Construisez votre propre compréhension des régions qui sont favorisées à ce moment-là, et alignez continuellement votre mise en page réseau en fonction des changements d'époque à époque.

Résumé: pourquoi commencer par la distance réseau

Si vous voulez construire des systèmes de trading ou de surveillance rapides sur Solana, vous devez penser au code, au matériel et au réseau en même temps. Parmi celles-ci, la distance réseau est:

Un des plus grands leviers d'amélioration
Une des sources de latence les plus souvent négligées

Tant que vous pourchassez des leaders de réseaux éloignés, il y aura toujours des créneaux où vous êtes physiquement incapable de gagner, peu importe comment optimisé votre code et les serveurs sont.

C'est pourquoi vous devriez:

Mesurez correctement votre distance réseau
Comprendre dans quels réseaux vous vous battez vraiment
Déplacez vos applications vers des endroits qui ont un sens pour Solana

Ce sont les premiers pas vers une véritable performance.

ERPC et Validators DAO fournissent des réseaux et des ressources serveur axés sur Solana pour rendre ces architectures réalistes et accessibles dans la pratique.

Si vous souhaitez discuter de l'optimisation de distance réseau ou comment structurer votre Bundle et VPS configuration, n'hésitez pas à contacter Discord officiel de Validators DAO.

site officiel d'ERPC: https://erpc.global/en
Discord officiel de Validators DAO: https://discord.gg/C7ZQSrCkYR