Pourquoi ERPC VPS offre une performance élevée

Lorsque les développeurs commencent à construire des applications ou des robots sur Solana, beaucoup choisissent naturellement de grands nuages à usage général en fonction de leur expérience passée. Dans le monde Web2, ces nuages ont été la norme et ont fourni des performances suffisantes. Il est donc naturel de supposer que la même approche serait également appropriée pour Solana.

Cependant, cette hypothèse se décompose considérablement pour les charges de travail de Solana. Les grands nuages à usage général sont conçus avec polyvalence et flexibilité comme étant leurs priorités les plus élevées, et pour les charges de travail comme Solana où la faible latence affecte directement les résultats, les différences structurelles deviennent immédiatement visibles.

Cet article explique, étape par étape et avec soin, pourquoi la charge de travail de Solana n'atteint pas la performance attendue sur les grands nuages à usage général, et comment ERPC VPS est structuré pour résoudre ces problèmes.

Pourquoi la lenteur du nuage est presque jamais remarquée dans Web2

Premièrement, la plupart des applications Web2 ne sont pas aussi essentielles que les applications financières. Des services tels que le SNS, le commerce électronique, les outils d'affaires et la livraison de contenu peuvent tolérer un certain nombre de retards et encore fonctionner comme des produits.

Pour cette raison, les sources suivantes de latence structurale à l'intérieur de grands nuages à usage général n'ont pas fait surface comme problèmes:

Multiples couches de virtualisation (NIC virtuels, commutateurs virtuels, etc.)
Bande passante interne partagée entre de nombreux utilisateurs
CPU surenchérir (signer plus de cœurs virtuels que de cœurs physiques)
Autres processus de facturation et de surveillance
Les générations plus âgées du CPU sont mises à la disposition des utilisateurs généraux

Ces mécanismes sont nécessaires pour les opérations en nuage, mais dans le Web2, leur impact est mineur et il y a peu d'occasions de les remarquer.

Les charges de travail de Solana sont fondamentalement différentes.

Les applications Web3 sont proches du financement, et tout peut devenir critique pour la mission

Les applications construites sur Solana et d'autres blockchains sont situées à proximité du domaine financier. Les mouvements d'actifs, les conditions de liquidation, les variations de prix et les ordres de transaction sont tous directement liés aux résultats.

En particulier, les charges de travail liées au marché exigent un volume de transactions et une vitesse dépassant largement les paiements traditionnels par carte. Même quelques millisecondes de retard peuvent conduire à une exécution ratée ou à une pire tarification.

De plus, le volume de données en chaîne de SolanaS est extrêmement important; s'abonner correctement à Shreds, aux journaux, et gRPC les événements peuvent facilement entraîner plusieurs téraoctets de données par jour. Ceci est fondamentalement différent des profils de trafic Web2 typiques pour lesquels de grands nuages ont été conçus à l'origine.

De cette façon, Solana n'offre aucune occasion de cacher les caractéristiques de la latence structurelle ou des coûts présents à l'intérieur de ces nuages. Dès le début, ces caractéristiques apparaissent directement comme des inconvénients ou des coûts opérationnels.

Pourquoi les grands nuages à usage général ne conviennent pas à Solana

Ci-dessous, nous expliquons, facteur par facteur, pourquoi les grands nuages à usage général sont structurellement décomposés avec les exigences à grande vitesse de Solana.

1. Les CPU disponibles pour les utilisateurs généraux sont vieux de plusieurs générations

Serveurs métalliques et VPS (VM) mis à disposition par les grands nuages utilisent généralement des processeurs qui sont plusieurs générations derrière. Les derniers processeurs haute-horloge ne s'alignent pas sur l'efficacité opérationnelle ou la stratégie d'inventaire du fournisseur et apparaissent donc rarement comme des options sélectionnables par l'utilisateur.

Pour les charges de travail de Solana, la performance à un seul fil et la structure du cache sont importantes, et les différences dans la génération de CPU affectent:

Combien de transactions peuvent être traitées
Combien de flux peuvent être manipulés sans tomber derrière
Comment traiter les données rapidement

2. De nombreuses couches de virtualisation et de longs chemins de réseau (latence réseau plus élevée)

Les grands nuages à usage général doivent exécuter simultanément de nombreuses applications différentes sur du matériel physique partagé. Pour ce faire, plusieurs couches de virtualisation et de réseautage interne sont ajoutées.

Voici quelques exemples:

Hyperviseurs pour le fonctionnement de machines virtuelles
NIC et commutateurs virtuels
Pare-feu et balanceurs de charge internes
Agents de facturation et de surveillance

Si nécessaire pour les opérations en nuage, du point de vue de Solanas:

Chacun allonge le réseau et le chemin de traitement
Chacun introduit la latence et la plaisanterie

Pour les charges de travail qui gèrent constamment les données de streaming telles que Shreds ou gRPC, ces points supplémentaires s'accumulent directement comme des inconvénients.

3. Surengagement crée des performances instables

Les grands nuages augmentent l'efficacité en exécutant de nombreuses machines virtuelles sur un seul serveur physique. Par exemple, un serveur doté d'un processeur physique 64-core peut héberger de nombreux VM 8-core ou 16-core, ajoutant jusqu'à bien plus de 64 cœurs virtuels.

Cette pratique, qui consiste à attribuer plus de cœurs virtuels que de cœurs physiques, est exagérée.

Les hypothèses sont les suivantes:

Tous les VM n'utiliseront pas 100% de leur CPU simultanément
Temps CPU peut être emprunté entre VMs en fonction de l'activité

Pour les charges de travail de Web2, ces hypothèses sont raisonnablement valables.

Cependant, les charges de travail de Solana incluent souvent plusieurs processus qui nécessitent simultanément un processeur important. Sur un serveur surengagé, la dispute CPU se produit plus fréquemment, et le système d'exploitation doit planifier les tâches dans une file d'attente.

En conséquence:

Les repères peuvent sembler rapides
La latence réelle dans la charge de travail réelle varie considérablement selon l'heure de la journée et les autres locataires.

Pour Solana, où le moment de la transaction et le moment du traitement du flux affectent directement les résultats, ce jeu est un désavantage majeur.

4. Des volumes élevés de transfert de données entraînent une facturation coûteuse fondée sur l ' utilisation

La surveillance sérieuse des données de la chaîne de Solana implique souvent plusieurs téraoctets de transfert quotidien à travers Shreds, les journaux, et gRPC les événements.

Les grands nuages chargent séparément pour:

Trafic de réseau sortant
Trafic de réseau interne
Stockage I/O

Dans le Web2, ces frais sont négligeables parce que le volume de trafic est faible. Mais pour les charges de travail de Solana, simplement s'abonner à des flux peut entraîner des frais de réseau de plusieurs centaines de dollars par jour, rendant le fonctionnement continu impossible.

Ainsi, les grands nuages à usage général sont structurellement et économiquement désalignés avec la charge de travail de Solana.

Pourquoi ERPC centres de données testés dans le monde entier

Pour comprendre ces contraintes, nous devions identifier les infrastructures qui convenaient réellement à Solana.

Pour ce faire, nous avons loué des centres de données dans le monde entier et avons géré de véritables charges de travail de Solana pour évaluer leur comportement.

Même dans la même ville, l'aptitude à Solana varie selon:

Bâtiment
Position du rack
Câble interne
IX et fournisseurs de transit
Performance et configuration du matériel réseau
Capacité des FSI et qualité du routage
La quantité et la qualité des voies physiques de fibres
Garanties de largeur de bande pendant la congestion

Au moyen de tests répétés, nous avons clairement identifié:

Les lieux qui se comportent de façon cohérente et coopérative pour Solana
Emplacements qui ne le font pas, peu importe les spécifications annoncées

Nous avons retiré ce dernier et affiné nos choix encore et encore, formant finalement notre infrastructure actuelle et notre architecture de réseau. Cette connaissance accumulée soutient directement la fondation de ERPC VPS et infrastructures RPC.

Pourquoi ERPC VPS offre des performances élevées

Ce qui suit explique comment ERPC VPS est conçu de façon structurelle pour supporter les charges de travail élevées de Solana.

Suppression des couches inutiles en se concentrant sur la charge de travail de Solana

Les grands nuages à usage général comprennent de nombreuses couches pour prendre en charge une grande variété d'applications. La plupart de ces couches ne fournissent pas de valeur directe pour Solana et créent plutôt de la latence.

En se concentrant sur la charge de travail de Solana, ERPC VPS supprime:

Couches inutiles pour le trafic de Solana
Composants présents uniquement pour les opérations cloud multi-usages

Un par un, de manière prudente et contrôlée.

Ce n'est pas une simplification pour son propre bien, mais un principe de conception: conserver seulement ce qui est significatif pour Solana et enlever tout le reste.

CPU de dernière génération et CEC DDR5 mémoire

Les grands nuages n'exposent généralement pas les processeurs de dernière génération aux utilisateurs. ERPC VPS adopte ces processeurs et fournit des configurations équivalentes à celles utilisées dans Solana RPC et ShredStream les nœuds.

Cela évite les goulots d'étranglement dus aux anciennes générations de processeurs et fournit une base capable de gérer l'indexation de Solanas, la logique de négociation et l'analyse en temps réel.

Pas de surengagement

Prime VPS Ne jamais surcommettre les cœurs du processeur physique. Chaque noyau alloué est soutenu directement par un noyau physique.

Cela évite:

Performance variable selon les autres locataires
Défaut de CPU sous charge lourde

Norme VPS maintient également des taux de surengagement extrêmement bas pour assurer un comportement CPU stable.

Les processeurs fonctionnent au turbo maximum en tout temps

De nombreux environnements serveurs ajustent dynamiquement la fréquence CPU pour des raisons de puissance ou thermique. Pour les charges de travail de Solana, cependant, une telle variabilité peut entraîner des baisses de performance à des moments critiques.

ERPC VPS est réglé de sorte que les processeurs fonctionnent à des vitesses d'horloge constamment élevées, minimisant les fluctuations vers le bas sous la charge et assurant la stabilité des performances.

Courir sur les hubs clés du réseau Solana

ERPC VPS n'est pas simplement situé près de notre propre infrastructure. Il fonctionne directement sur les réseaux où les validateurs et le stake de Solana sont concentrés au niveau mondial.

Norme VPS est déployé sur un réseau classé au deuxième rang mondial en nombre et en enjeux de validation. Prime VPS les circuits sur le réseau se classent au premier rang mondial dans les deux métriques, directement connectés à un pôle majeur où les leaders et les validateurs de base convergent.

Ainsi, ERPC VPS:

Partage le même réseau que ERPC RPC, gRPC et ShredStream les infrastructures, et
Fonctionne sur les réseaux mêmes où les validateurs et le stake sont les plus concentrés

Cela rapproche physiquement et logiquement la charge de travail des leaders.

En conséquence, même le code et la logique identiques présenteront des performances structurellement différentes lors de l'exécution ERPC VPS par rapport aux grands nuages d'usage général, en particulier dans la détection et la soumission des transactions par les leaders.

RAID0 configuration de stockage

De nombreux nuages et VPS les fournisseurs privilégient la protection des données et donc l'utilisation RAID10 ou RAID4/5/6. Pour les systèmes Web2 où les données utilisateur résident sur le serveur, cela est approprié.

Cependant, de nombreuses applications Web3 et les nœuds Solana ne conservent pas un seul élément de données irremplaçable à la couche d'application. La blockchain elle-même sert de grand livre distribué, rendant possible la resynchronisation ou la reconstruction.

De nombreux utilisateurs préfèrent aussi la performance sur le miroir, et le stockage I/O La performance affecte directement le comportement du nœud Solana. Pour ces raisons, ERPC VPS Utilisations RAID0 pour maximiser I/O le débit.

Dans l'infrastructure Web3, choisir où placer la redondance et à quelle couche est essentielle pour équilibrer performance et sécurité.

Référence: Essais de vitesse du monde réel pour différents niveaux RAID SSD https://larryjordan.com/articles/real-world-speed-results-for-different-raid-levels/

Conclusion

Il n'y a aucun facteur qui explique la performance de ERPC VPS.

Génération de processeurs, politique de surengagement, élimination des contraintes d'économie d'énergie et fonctionnement au turbo maximum, sélection des centres de données, chemins de réseau, configuration RAID, et dans quelle mesure les couches inutiles sont éliminées pour les charges de travail de Solana – chacun de ces facteurs peut sembler petit à lui seul, mais lorsque chacun est complètement affiné, l'effet cumulatif devient la performance ERPC VPS livre aujourd'hui.

Grâce à ces efforts, nous avons construit une infrastructure fondamentalement différente des grands nuages d'usage général, une infrastructure spécialisée pour les charges de travail de Web3 et de blockchain. Pour Solana, cette différence structurelle se traduit directement en avantages de performance significatifs.

Pour les questions de configuration, les discussions d'utilisation ou la planification du déploiement, n'hésitez pas à nous contacter par Validators DAO Discord.

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