«¿Por qué sigue aumentando la latencia de mi ShredStream de Solana?» Causas y soluciones
En ERPC recibimos a menudo consultas de clientes que utilizan el flujo de datos en tiempo real de Solana y afirman que «la latencia de ShredStream aumenta gradualmente hasta que se detiene».
En este artículo explicamos las principales causas y ofrecemos soluciones concretas para mejorar el rendimiento de la aplicación.
Por qué sigue aumentando la latencia de ShredStream
Actualmente, ShredStream transmite casi todos los datos en tiempo real sin filtros. Si la capacidad de procesamiento del cliente es insuficiente, los datos se acumulan y la latencia aumenta poco a poco.
Las causas principales son las siguientes:
1. Procesamiento con Node.js o entornos de un solo hilo
El cliente ShredStream se creó inicialmente con TypeScript y el protocolo gRPC. Como los filtros aún no están implementados, un entorno de un solo hilo como Node.js alcanza rápidamente sus límites de procesamiento y la latencia crece continuamente.
Comprobamos que el problema no aparece al utilizar un cliente Rust en la misma máquina, lo que confirma la limitación del procesamiento en un solo hilo.
Solución: varios hilos con NAPI-RS
Como respuesta, desarrollamos una solución basada en NAPI-RS que permite procesar en Rust con varios hilos y mantener el control desde TypeScript. La solución, llamada Solana Stream SDK, es de código abierto y está disponible públicamente:
- GitHub: ValidatorsDAO/solana-stream
Si utilizas Node.js o TypeScript, recomendamos encarecidamente este SDK. Para obtener el máximo rendimiento, considera un lenguaje nativo multihilo como Rust.
2. Rendimiento insuficiente del servidor, especialmente la frecuencia de la CPU
Las aplicaciones en tiempo real que usan Solana ShredStream suelen funcionar correctamente en un servidor con 4 núcleos y 16 GB de RAM. Sin embargo, la frecuencia de reloj de la CPU es extremadamente importante. Una frecuencia baja puede hacer que la latencia aumente gradualmente.
Los servidores diseñados para maximizar beneficios suelen usar CPU antiguas o con muchos núcleos pero frecuencias bajas. Por ejemplo, las CPU AMD EPYC de 4.ª generación con muchos núcleos, como los modelos de 84, suelen tener una frecuencia base de unos 2,2 GHz y a menudo no aprovechan bien el turbo. Como los requisitos mínimos recomendados para validadores de Solana son 2,8 GHz, aconsejamos que los clientes utilicen al menos esa frecuencia.
Además, los proveedores de VPS suelen usar «sobreasignación», es decir, dividir un servidor físico entre varios servidores virtuales. En estos entornos, la competencia por los recursos con otros usuarios aparece a menudo en horas punta y afecta negativamente al rendimiento.
Solución: un VPS con CPU recientes y de alta frecuencia
ERPC ofrece VPS con CPU AMD EPYC de última generación y frecuencias de hasta 4,15 GHz. Su rendimiento se aproxima al de soluciones bare metal y resulta idóneo para las cargas de Solana que necesitan datos en tiempo real.
Antes no existían VPS de alta frecuencia y los usuarios que necesitaban rendimiento en tiempo real debían elegir servidores bare metal. Los VPS de ERPC resuelven esa limitación.
Recomendamos nuestros VPS EPYC de alto rendimiento
Los VPS de ERPC están optimizados para datos en tiempo real de Solana y cuentan con una gran valoración entre traders de alta frecuencia y proyectos.
Son ideales para quienes necesitan alto rendimiento sin requerir todos los recursos de un servidor bare metal.
Te invitamos a probarlos.
Para pruebas gratuitas o consultas detalladas, visita el Discord oficial de Validators DAO:
- Discord oficial de Validators DAO: https://discord.gg/C7ZQSrCkYR
ERPC mantendrá la investigación y el desarrollo para responder a tus necesidades y mejorar el rendimiento.
Gracias por tu apoyo constante.
