VPS y Bare Metal para Solana: pruebas de CPU, UDP y red

Por qué importa tanto el servidor como el stream de Solana

Contratar un stream rápido de Solana no garantiza que la aplicación reciba la información a tiempo. Una CPU con poca carga y un puerto anunciado de 1 Gbps no explican por sí solos la recepción incompleta. Hay que estudiar el recorrido completo hasta que los datos resulten utilizables. Este artículo utiliza investigaciones anonimizadas, pruebas independientes y benchmarks publicados, sin responsabilizar a un proveedor por causas no confirmadas.

Alta velocidad y enormes flujos de paquetes

Shreds y Yellowstone Geyser gRPC pueden enviar datos continuamente y en ráfagas. Ancho de banda, paquetes por segundo (PPS), RTT, variación, pérdida y procesamiento son métricas diferentes. Un flujo hipotético de 4 MB/s durante 30 días suma unos 10,4 TB, pero promedia 32 Mbps. No basta para declarar insuficiente 1 Gbps; también importan los límites UDP, las ráfagas, los enlaces compartidos y el receptor.

El stream funciona, pero faltan datos

En una investigación anonimizada se observaron unos 3.400–3.900 paquetes UDP/s en el origen y, en otro momento, se comunicaron unos 13 paquetes/s en el receptor. Los Shreds recibidos eran válidos, pero no alcanzaban para reconstruir los datos. gRPC funcionaba en el mismo equipo. Son mediciones de momentos y lugares distintos: no prueban una tasa de pérdida ni una causa. Miles de PPS no son necesariamente demasiados para un servidor corriente.

Encontrar el punto de observación

Antes de llegar a la VM, UDP puede sufrir restricciones por políticas de red, protección DDoS o el hipervisor. Tras la NIC, el kernel, los buffers de socket y la aplicación también pueden descartar paquetes. Empiece con tcpdump, luego revise contadores NIC, errores UDP y colas de aplicación. XDP puede descartar antes de que tcpdump vea los paquetes. Compare periodos y filtros equivalentes antes de atribuir responsabilidades.

Cerca en el mapa no implica cerca en la red

Dos servidores en Frankfurt pueden usar instalaciones y redes separadas y atravesar tránsito externo. Desde el mismo host se midieron unos 11 ms y 23 ms de RTT hacia dos endpoints de Amsterdam que entre sí estaban a aproximadamente 0,1 ms. Otra ventana presentó pérdidas del 5–8 % y unos 5 ms de retraso añadido en la red superior. Estos valores describen rutas concretas, no todos los proveedores.

Ejecutar cerca de la fuente de datos

Normalmente el proveedor RPC y la empresa de servidores venden servicios distintos. ERPC diseña conjuntamente Shreds, Geyser gRPC, RPC, VPS y Bare Metal. En ubicaciones compatibles pueden comunicarse mediante red local entre racks cercanos y evitar desvíos externos innecesarios. Zero-Distance Communication no significa latencia literalmente cero ni una garantía universal. Debe medirse la ruta real.

Medir los datos que llegan a la aplicación

Con una suscripción Geyser gRPC comparable al mismo endpoint de Amsterdam, un host externo registró 3,7–4,2 MiB/s con retraso creciente. Una prueba independiente desde un VPS ERPC en Frankfurt, limitada a un núcleo, promedió 9,396 MiB/s y unas 1.910 transacciones/s durante 60 segundos sin retraso acumulado. Se observaron retransmisiones TCP en la ruta problemática. Como las implementaciones y los equipos diferían, no es una prueba A/B controlada. Otra prueba HTTP/2 produjo 2,7 MB/s con ventana de 16 KiB y hasta 7,1 MB/s con una ventana mayor.

El modelo de CPU oculta límites importantes

Con la misma generación de CPU y cantidad de vCPU pueden existir diferentes políticas de boost, energía, temperatura y planificación. AMD Core Performance Boost e Intel Turbo Boost pueden desactivarse en el host o BIOS. Incluso habilitados, no garantizan frecuencia máxima sostenida. Una VM podría no mostrar la configuración del anfitrión. Hay que medir rendimiento continuo en la carga real.

Cuatro vCPU y una diferencia medida de 1,93×

La comparación publicada de ERPC entre sistemas AMD Turin de cuatro vCPU con Ubuntu 24.04 en Amsterdam registra 7.850 frente a 4.062 eventos/s en sysbench CPU: aproximadamente 1,93× en esas condiciones. También publica diferencias cercanas a 3,2× en ancho de banda de memoria y 16,6× en IOPS de lectura aleatoria de 4K. No son garantías para todas las aplicaciones ni prueban que el boost sea la única causa.

La economía del centro de datos afecta al rendimiento

Energía, refrigeración, racks, conmutadores y enlaces tienen costes. Compartir recursos resulta razonable para aplicaciones habituales. Las cargas Solana de alto rendimiento pueden demandar CPU, PPS y enlaces durante periodos prolongados. Anchos de banda compartidos, límites por flujo y protección DDoS pueden ser adecuados para otros usos. No se trata de señalar a una empresa, sino de comprobar si su política encaja con la aplicación.

Los costes de transferencia cloud también importan

Un stream continuo acumula terabytes aunque la media parezca modesta. Muchos servicios cloud no cobran el tráfico entrante de Internet, pero sí algunas transferencias salientes, entre zonas o entre servicios. Los productos ERPC elegibles diferencian tráfico interno de la plataforma y cuotas de transferencia externa; consulte las condiciones actuales. El coste total de la ruta es más relevante que solo el precio de la VM.

Elegir según la carga de trabajo

Un EPYC VPS puede ser suficiente para RPC ligero. Una suscripción gRPC intensa exige CPU y memoria sostenidos; Shreds UDP y aplicaciones sensibles a latencia necesitan probar admisión, PPS, ráfagas y tiempo de detección. Bare Metal permite recursos físicos exclusivos, pero no es automáticamente más rápido. Dividir trabajo entre varios VPS también puede ayudar. Compare filtros, software y tiempos idénticos: Shreds válidos, reconstrucción, lag, retransmisiones y latencia p95/p99.

Medir antes de comprometerse

En Linux, tcpdump, nstat, ip -s link, ethtool -S, ss -tin y lscpu proporcionan observaciones iniciales sin cambiar configuraciones. Sustituya interfaz e IP de ejemplo, compare incrementos y tenga en cuenta pérdidas en la propia captura. lscpu no demuestra la política de boost del hipervisor. ERPC ofrece uso por horas en configuraciones VPS y Bare Metal elegibles, según disponibilidad. Elija la máquina que entregue los datos útiles dentro del tiempo requerido.

bash

IFACE=ens3
SRC_IP=203.0.113.10  # documentation address; replace with real sender IP
PORT=2000
sudo timeout -s INT 10 tcpdump -nni "$IFACE" -l -q \
  "udp and src host $SRC_IP and dst port $PORT" 2>/dev/null | wc -l
nstat -az UdpInErrors UdpRcvbufErrors
ip -s link show dev "$IFACE"
sudo ethtool -S "$IFACE" | grep -Ei 'drop|miss|err|fifo'
ss -tin
lscpu

IFACE=ens3
SRC_IP=203.0.113.10  # documentation address; replace with real sender IP
PORT=2000
sudo timeout -s INT 10 tcpdump -nni "$IFACE" -l -q \
  "udp and src host $SRC_IP and dst port $PORT" 2>/dev/null | wc -l
nstat -az UdpInErrors UdpRcvbufErrors
ip -s link show dev "$IFACE"
sudo ethtool -S "$IFACE" | grep -Ei 'drop|miss|err|fifo'
ss -tin
lscpu