Por qué ERPC VPS ofrece un alto rendimiento

Cuando los desarrolladores comienzan a construir aplicaciones o bots en Solana, muchos naturalmente eligen grandes nubes de uso general basadas en su experiencia pasada.
En el mundo Web2, estas nubes han sido efectivamente el estándar, y han proporcionado un rendimiento suficiente.
Por lo tanto, es natural suponer que el mismo enfoque sería adecuado para Solana también.

Sin embargo, esta hipótesis descompone significativamente las cargas de trabajo de Solana.
Grandes nubes de uso general están diseñadas con versatilidad y flexibilidad como sus máximas prioridades, y para cargas de trabajo como Solana donde la baja latencia afecta directamente los resultados, las diferencias estructurales se vuelven visibles inmediatamente.

Este artículo explica, paso a paso y con cuidado, por qué las cargas de trabajo de Solana no alcanzan el rendimiento esperado en grandes nubes de uso general, y cómo ERPC VPS está estructurado para resolver estas cuestiones.

¿Por qué “la lentitud cercana” casi nunca se nota en Web2

En primer lugar, la mayoría de las aplicaciones Web2 no son tan críticas como las aplicaciones financieras.
Los servicios como SNS, comercio electrónico, herramientas de negocios y la entrega de contenidos pueden tolerar una cierta cantidad de retraso y seguir funcionando como productos.

Por esta razón, las siguientes fuentes de latencia estructural dentro de grandes nubes de uso general no surgieron como problemas:

Múltiples capas de virtualización (NIC virtuales, conmutadores virtuales, etc.)
Ancho de banda interno compartido entre muchos usuarios
CPU sobrecommit (asignando más núcleos virtuales que núcleos físicos)
Procesos adicionales para facturación y monitoreo
Las generaciones de CPU más antiguas están disponibles para los usuarios generales

Estos mecanismos son necesarios para las operaciones en la nube, pero en la Web2 su impacto es menor, y hay pocas oportunidades para notarlos.

Las cargas de trabajo de Solana son fundamentalmente diferentes.

Las aplicaciones web3 se sientan “adyacentes para financiar”, y todo puede convertirse en crítico de misión

Las aplicaciones construidas en Solana y otras blockchains se encuentran cerca del dominio financiero.
El movimiento de activos, las condiciones de liquidación, los cambios de precio y el orden de transacción están directamente vinculados a los resultados.

En particular, las cargas de trabajo relacionadas con el mercado requieren un volumen de transacción y una velocidad superiores a los pagos tradicionales basados en tarjetas.
Incluso unos pocos milisegundos de retraso pueden llevar a una ejecución fallida o a un precio peor.

Además, el volumen de datos de la cadena de Solana es extremadamente grande; subscribiendo correctamente a Shreds, logs y gRPC eventos pueden resultar fácilmente en varios terabytes de datos por día.
Esto es fundamentalmente diferente de los perfiles de tráfico Web2 típicos para los cuales las nubes grandes fueron originalmente diseñadas.

De esta manera, Solana no ofrece oportunidad para ocultar las características estructurales de latencia o costo presentes dentro de estas nubes.
Desde el principio, estas características aparecen directamente como desventajas o costos operativos.

Por qué las grandes nubes de uso general no son adecuadas para Solana

A continuación explicamos, factor por factor, por qué las grandes nubes de uso general están estructuralmente desajustadas con los requisitos de alta velocidad de Solana.

1. Las CPU disponibles para los usuarios generales son varias generaciones de edad

Bare metal servers and VPS (VMs) disponible por grandes nubes generalmente usan CPU que están varias generaciones detrás.
Las últimas CPU de alta velocidad no se ajustan a la estrategia de eficiencia operativa o inventario del proveedor, por lo que rara vez aparecen como opciones seleccionables para el usuario.

Para las cargas de trabajo de Solana, el rendimiento de un solo hilo y la estructura de caché son importantes, y las diferencias en la generación de CPU afectan:

¿Cuántas transacciones se pueden procesar?
¿Cuántas corrientes se pueden manejar sin caer detrás
Cómo se pueden procesar datos rápidos

2. Muchas capas de virtualización y largas rutas de red (latencia de red más alta)

Las grandes nubes de uso general deben ejecutar muchas aplicaciones simultáneamente en hardware físico compartido.
Para apoyar esto, se añaden múltiples capas de virtualización y redes internas.

Por ejemplo:

Hipervisores para máquinas virtuales
NIC virtuales y conmutadores
cortafuegos internos y balanceadores de carga
Agentes de facturación y vigilancia

Si bien es necesario para las operaciones en la nube, desde la perspectiva de Solana:

Cada uno alarga la red y la ruta de tratamiento
Cada uno presenta la latencia y el jitter

Para las cargas de trabajo que manejan constantemente datos de transmisión, como Shreds o gRPC, estos “puntos adicionales” se acumulan directamente como desventajas.

3. El exceso de compromiso crea un rendimiento inestable

Las grandes nubes aumentan la eficiencia ejecutando muchas máquinas virtuales en un servidor físico.
Por ejemplo, un servidor con una CPU física de 64 núcleos puede albergar muchos VM de 8 núcleos o 16 núcleos, sumando hasta mucho más de 64 núcleos virtuales.

Esta práctica —asignar más núcleos virtuales que los núcleos físicos— es sobrecommitida.

Las hipótesis son:

No todos los VM utilizarán el 100% de su CPU simultáneamente
El tiempo de CPU puede ser prestado entre VM dependiendo de la actividad

Para las cargas de trabajo de la Web2, estas hipótesis son razonablemente válidas.

Sin embargo, las cargas de trabajo de Solana a menudo incluyen múltiples procesos que simultáneamente requieren una CPU significativa.
En un servidor overcommitted, la contención de CPU ocurre con más frecuencia, y el sistema operativo debe programar tareas en una cola.

En consecuencia:

Los parámetros pueden verse rápido
Latencia real en cargas de trabajo reales varía significativamente dependiendo del tiempo del día y de la carga de otros inquilinos

Para Solana —donde el tiempo de transacción y el tiempo de tratamiento de flujo afectan directamente los resultados— este jitter es una desventaja importante.

4. Los volúmenes elevados de transferencia de datos dan lugar a una facturación basada en el uso costosa

El monitoreo serio de los datos de la cadena de Solana frecuentemente implica varios terabytes de transferencia diaria a través de Shreds, registros y gRPC eventos.

Las nubes grandes cobran por separado para:

Tráfico de red
A veces tráfico de red interno
Almacenamiento I/O

En las cargas de trabajo de Web2, estos cargos son insignificantes porque el volumen de tráfico es pequeño.
Pero para las cargas de trabajo de Solana, simplemente suscribirse a las corrientes puede resultar en cargas de red de varios cientos de dólares diarios, haciendo que el funcionamiento continuo sea poco práctico.

Por lo tanto, las grandes nubes de uso general se armonizan estructural y económicamente con las cargas de trabajo de Solana.

¿Por qué? ERPC centros de datos probados en todo el mundo

Entendiendo estas limitaciones, necesitábamos identificar la infraestructura que en realidad era adecuada para Solana.

Para ello, alquilamos centros de datos en todo el mundo y realizamos cargas de trabajo reales de Solana para evaluar su comportamiento.

Incluso dentro de la misma ciudad, la idoneidad para Solana varía dependiendo de:

Estructura del edificio
Posición de la cubierta
Cableado interno
IXes y proveedores de tránsito
Rendimiento y configuración del hardware de red
Capacidad de ISP y calidad de enrutamiento
La cantidad y calidad de las rutas de fibra física
Garantías de ancho de banda durante la congestión

A través de pruebas repetidas, identificamos claramente:

Lugares que se comportan de forma coherente y cooperativa para Solana
Lugares que no, independientemente de las especificaciones anunciadas

Retiramos a este último y refinamos nuestras opciones una y otra vez, formando finalmente nuestra actual infraestructura y arquitectura de red.
Este conocimiento acumulado apoya directamente la fundación de ERPC VPS y RPC infraestructura.

¿Por qué? ERPC VPS entrega alto rendimiento

A continuación se explica cómo ERPC VPS está diseñado estructuralmente para soportar las cargas de trabajo de Solana de alto rendimiento.

Eliminación de capas innecesarias centrándose en las cargas de trabajo de Solana

Las grandes nubes de uso general incluyen muchas capas para soportar una gran variedad de aplicaciones.
La mayoría de estas capas no proporcionan valor directo para Solana y en cambio crean latencia.

Centrándose en las cargas de trabajo de Solana, ERPC VPS elimina:

Capas innecesarias para el tráfico de Solana
Componentes presentes sólo para operaciones de nube multipropósito

uno por uno, de manera cuidadosa y controlada.

Esto no es “simplificación por su propio bien” sino un principio de diseño:
retener sólo lo que es significativo para Solana y eliminar todo lo demás.

CPU de última generación y ECC DDR5 memoria

Las grandes nubes generalmente no exponen CPU de última generación a los usuarios.
ERPC VPS adopta estas CPU y entrega configuraciones equivalentes a las utilizadas en Solana RPC y Shredstream nodos.

Esto evita los cuellos de botella debido a las viejas generaciones de CPU y proporciona una base capaz de manejar la indexación de Solana, lógica comercial y analítica en tiempo real.

No hay sobrecomiso

Premium VPS nunca supera los núcleos de CPU físicos.
Cada núcleo asignado está respaldado directamente por un núcleo físico.

Esto evita:

El rendimiento varía dependiendo de otros inquilinos
Contención de CPU bajo carga pesada

Estándar VPS También mantiene tasas de sobrecompromiso extremadamente bajas para garantizar un comportamiento estable de CPU.

Las CPU operan al máximo turbo en todo momento

Muchos entornos de servidor ajustan dinámicamente la frecuencia de la CPU por razones de energía o térmica.
Sin embargo, para las cargas de trabajo de Solana, esa variabilidad puede causar dips de rendimiento en momentos críticos.

ERPC VPS se sintoniza para que las CPU funcionen a velocidades de reloj siempre altas, minimizando la fluctuación hacia abajo bajo carga y garantizando la estabilidad del rendimiento.

Corriendo en los principales centros de red de Solana

ERPC VPS no es simplemente “situado cerca de nuestra propia infraestructura”.
Corre directamente en las redes donde los validadores de Solana y la participación están concentrados globalmente.

Estándar VPS está desplegada en una red clasificada en segundo lugar en todo el mundo en cuenta de validador y participación.
Premium VPS se ejecuta en la red clasificada en primer lugar a nivel mundial en ambas métricas, directamente conectada a un centro importante donde convergen líderes y validadores básicos.

Así, ERPC VPS:

Comparte la misma red que ERPC RPC, gRPC, y Shredstream infraestructura y
Opera en las mismas redes donde los validadores y la stake están más concentrados

Esto coloca la carga de trabajo física y lógicamente más cerca de los líderes.

Como resultado, incluso código y lógica idénticos mostrarán un rendimiento estructuralmente diferente cuando se ejecuta ERPC VPS en comparación con las grandes nubes de uso general, especialmente en la detección y la presentación de transacciones de líder-adyacente.

RAID0 configuración de almacenamiento

Muchas nubes VPS Los proveedores priorizan la protección de datos y, por lo tanto, utilizan RAID10 o RAID4/5/6.
Para los sistemas Web2 donde los datos de usuario residen en el servidor, esto es apropiado.

Sin embargo, muchas aplicaciones Web3 y nodos de Solana no conservan una sola pieza irremplazable de datos en la capa de aplicación.
La cadena de bloques en sí sirve como un libro mayor distribuido, haciendo posible la sincronización o reconstrucción.

Muchos usuarios también prefieren el rendimiento sobre el replicar, y el almacenamiento I/O El rendimiento afecta directamente al comportamiento de los ganglios Solana.
Por estas razones, ERPC VPS usos RAID0 para maximizar/O a través.

En la infraestructura Web3, elegir dónde colocar la redundancia y en qué capa es esencial para equilibrar el rendimiento y la seguridad.

Referencia: Pruebas de velocidad en el entorno real para diferentes niveles RAID SSD
https://larryjordan.com/articles/real-world-speed-results-for-different-raid-levels/

Conclusión

No hay un solo factor que explique el rendimiento de ERPC VPS.

Generación de CPU, política de sobrecompromiso, eliminando las restricciones de ahorro de energía y corriendo al máximo turbo, selección de centros de datos, rutas de red, configuración RAID, y cuán lejos se eliminan las capas innecesarias para las cargas de trabajo de Solana, cada uno de estos factores puede parecer pequeño por sí mismo, pero cuando cada uno es completamente refinado, el efecto acumulativo se convierte en el rendimiento ERPC VPS entrega hoy.

A través de estos esfuerzos hemos construido una infraestructura fundamentalmente diferente de las grandes nubes de uso general, una infraestructura especializada en la Web3 y la carga de trabajo de blockchain.
Para Solana, esta diferencia estructural se traduce directamente en ventajas significativas de rendimiento.

Para consultas de configuración, discusiones de casos de uso o planificación del despliegue, por favor no dude en contactarnos a través de la Validators DAO Discord.

ERPC Sitio oficial: https://erpc.global/
Discord oficial de Validators DAO: https://discord.gg/C7ZQSrCkYR