Latencia RPC lenta: causas, medición y soluciones

¿Qué causa la latencia RPC lenta?

Cuando tu aplicación blockchain se siente lenta, el primer sospechoso suele ser el endpoint RPC. Pero la 'latencia RPC' no es un número único; es una combinación del tiempo de ida y vuelta de la red, el tiempo de procesamiento del nodo y los retrasos de cola. Comprender cada componente es el primer paso para solucionarlo.

La latencia total que observas es la suma de: latencia de red (el tiempo que tardan los paquetes en viajar entre tu cliente y el nodo), tiempo de procesamiento del nodo (cuánto tarda el nodo en ejecutar la solicitud, lo que depende del método y de la carga del nodo) y retraso de cola (si el nodo está ocupado, tu solicitud espera en la fila). Por ejemplo, una solicitud simple eth_blockNumber puede tomar 10 ms en un nodo local, pero 200 ms en un endpoint público al otro lado del océano.

El factor dominante suele ser la distancia de red. La luz viaja aproximadamente 5 ms por cada 1,000 km en fibra, pero la latencia del mundo real es mayor debido al enrutamiento y la congestión. Una solicitud desde Nueva York a un nodo en Tokio puede fácilmente tomar 150-200 ms de ida y vuelta. La carga del nodo es el segundo factor importante: si el nodo está procesando muchas consultas pesadas (como eth_getLogs en un rango amplio), tu solicitud puede quedar en cola detrás de ellas.

Finalmente, la consulta en sí importa. Algunos métodos RPC son inherentemente costosos. Por ejemplo, eth_getLogs con un rango de bloques amplio puede tomar segundos, mientras que eth_blockNumber es casi instantáneo. Si tu aplicación realiza llamadas costosas con frecuencia, verás alta latencia incluso con un nodo rápido.

Para obtener una imagen clara, necesitas medir cada componente por separado. El resto de este artículo te muestra cómo.

• Latencia de red: tiempo de ida y vuelta entre el cliente y el nodo, afectado por la geografía y el enrutamiento.
• Tiempo de procesamiento del nodo: tiempo que tarda el nodo en ejecutar la solicitud, depende del método y la carga.
• Retraso de cola: tiempo de espera para que el nodo se libere, aumenta bajo carga.
• Costo de la consulta: algunos métodos (por ejemplo, eth_getLogs) son mucho más lentos que otros.

Cómo medir la latencia RPC de manera reproducible

Para medir la latencia RPC, puedes usar curl con la opción -w para capturar detalles de tiempo. Esto te da un método reproducible que no requiere herramientas especiales. Aquí hay un comando que envía una solicitud simple eth_blockNumber a un endpoint público e imprime el tiempo total:

Ejecuta este comando varias veces para tener una idea de la distribución. El time_total es el tiempo total de la solicitud HTTP, incluyendo red y procesamiento del nodo. Para separar la latencia de red del procesamiento del nodo, puedes usar time_connect (handshake TCP) y time_starttransfer (tiempo hasta el primer byte).

Para una medición más robusta, debes recolectar múltiples muestras y calcular percentiles. El p50 (mediana) te dice la latencia típica, mientras que el p99 (percentil 99) revela la latencia de cola, que es crítica para la experiencia del usuario. Puedes usar un script simple para enviar 100 solicitudes y calcular estos valores.

Aquí hay un script bash que envía 100 solicitudes y calcula p50, p95 y p99 usando awk y sort. Asume que tienes curl y jq instalados.

curl -s -o /dev/null -w "time_total: %{time_total}s\n" -X POST https://eth.api.onfinality.io/public -H "Content-Type: application/json" --data '{"jsonrpc":"2.0","method":"eth_blockNumber","params":[],"id":1}'

Interpretando los números: ¿Qué es una latencia RPC 'buena'?

Una vez que tengas mediciones, necesitas una línea base. Para un endpoint RPC público, un p50 de menos de 100 ms es generalmente aceptable, y menos de 50 ms es bueno. Sin embargo, para aplicaciones de trading o interacciones en tiempo real, puedes necesitar p99 por debajo de 100 ms. Como referencia, un tiempo de ida y vuelta típico desde un cliente en la costa este de EE. UU. a un nodo en la costa oeste es de aproximadamente 70 ms; a Europa es de unos 140 ms; a Asia es de 200 ms o más.

Si tu p50 es alto pero el p99 es mucho más alto, probablemente tienes un problema de carga del nodo. Si ambos son altos, probablemente sea la distancia de red. Puedes probar esto comparando un nodo local (si tienes uno) con un endpoint público remoto. Si el nodo local es mucho más rápido, la red es el cuello de botella.

También considera el método que estás midiendo. eth_blockNumber es el método más barato; si es lento, todo lo demás será más lento. Para una prueba más realista, mide los métodos reales que usa tu aplicación, como eth_getBalance o eth_call.

Recuerda que la latencia no es lo mismo que el rendimiento. Un nodo puede tener baja latencia pero bajo rendimiento, o viceversa. Para aplicaciones de alto rendimiento, puede que necesites procesar por lotes o usar suscripciones WebSocket para reducir el número de viajes de ida y vuelta.

• p50 < 100 ms: aceptable para la mayoría de endpoints públicos.
• p50 < 50 ms: bueno para aplicaciones interactivas.
• p99 < 100 ms: requerido para trading o aplicaciones en tiempo real.
• Compara p50 vs p99 para identificar problemas de carga vs. red.

Reduciendo la latencia: endpoints geográficos y selección de proveedor

La forma más efectiva de reducir la latencia de red es usar un endpoint que esté geográficamente cerca de tu aplicación. Si tus usuarios están en Europa, usa un endpoint europeo; si están en Asia, usa uno asiático. Muchos proveedores, incluido OnFinality, ofrecen endpoints regionales. Por ejemplo, los endpoints RPC de Polkadot de OnFinality incluyen opciones en diferentes regiones.

Al elegir un proveedor, busca uno con una red de borde global. El servicio RPC de OnFinality enruta las solicitudes al nodo más cercano, reduciendo el tiempo de ida y vuelta. De manera similar, para Ethereum, puedes usar las mejores APIs RPC de Ethereum que ofrecen acceso de baja latencia.

Si estás construyendo un bot de trading en Hyperliquid, la latencia es crítica. Consulta nuestra guía sobre los mejores proveedores RPC de Hyperliquid para trading de baja latencia para ver qué proveedores ofrecen las conexiones más rápidas.

Para Solana, la red está diseñada para alto rendimiento, pero la latencia aún importa. Consulta nuestra página de endpoints RPC de Solana para ver proveedores recomendados.

Finalmente, considera ejecutar tu propio nodo si tienes los recursos. Un nodo local elimina por completo la latencia de red, pero requiere mantenimiento y puede ser lento si el nodo no tiene suficiente potencia. Para muchas aplicaciones, un endpoint público bien elegido es suficiente.

Reduciendo la latencia: procesamiento por lotes, suscripciones y caché

Incluso con una red rápida, puedes reducir la latencia percibida reduciendo el número de viajes de ida y vuelta. El procesamiento por lotes JSON-RPC te permite enviar múltiples solicitudes en una sola solicitud HTTP, reduciendo la sobrecarga de red. Por ejemplo, si necesitas obtener 10 saldos, puedes enviar una solicitud por lotes en lugar de 10 solicitudes separadas. Esto es especialmente efectivo en redes de alta latencia.

Aprende cómo implementar el procesamiento por lotes correctamente en nuestro artículo sobre mejores prácticas de procesamiento por lotes JSON-RPC. El procesamiento por lotes puede reducir el tiempo total de N * latencia a aproximadamente latencia + N * tiempo_de_procesamiento, lo cual es una gran ventaja.

Otra técnica es usar suscripciones WebSocket en lugar de sondeo. Las suscripciones te envían datos cuando cambian, eliminando la necesidad de solicitudes repetidas. Esto es ideal para aplicaciones en tiempo real como feeds de precios o monitoreo de transacciones. Las conexiones WebSocket también tienen menor sobrecarga después del handshake inicial.

El caché también es poderoso. Si estás obteniendo los mismos datos repetidamente (por ejemplo, números de bloque, precios de gas), almacénalos en caché en el cliente y actualízalos a un intervalo razonable. Esto reduce la carga en el nodo y mejora la capacidad de respuesta de tu aplicación.

Finalmente, considera usar un nodo dedicado si tienes alto tráfico. Los endpoints públicos son compartidos, por lo que puedes experimentar limitación de velocidad o colas. Un nodo dedicado te da un rendimiento consistente. OnFinality ofrece nodos dedicados con SLAs.

Diagnosticando problemas comunes de latencia

Si has medido y tu latencia sigue siendo alta, aquí hay problemas comunes a verificar:

1. Resolución DNS: El tiempo para resolver el nombre de host del endpoint puede agregar 10-50 ms. Usa curl -w "time_namelookup: %{time_namelookup}s\n" para medirlo. Si es alto, considera usar una dirección IP directamente o un proveedor de DNS más rápido.

2. Handshake TLS: HTTPS agrega un handshake que puede tomar 20-100 ms. Usa time_appconnect para medirlo. No puedes evitar TLS, pero puedes reutilizar conexiones con keep-alive.

3. Sobrecarga del nodo: Si el nodo está devolviendo errores o respuestas lentas, puede estar sobrecargado. Verifica la página de estado del nodo o usa un endpoint de verificación de salud. Si estás usando un endpoint público, prueba con otro para comparar.

4. Firewall o proxy: Las redes corporativas o VPN pueden agregar latencia. Prueba desde una red diferente para aislar.

5. Problemas del lado del cliente: Tu aplicación podría estar haciendo solicitudes secuencialmente cuando podrían ser paralelas. Usa llamadas asíncronas o procesamiento por lotes.

Para un enfoque sistemático, lee nuestra guía sobre monitoreo de endpoints RPC para configurar alertas de picos de latencia.

Compensaciones y limitaciones

Si bien puedes reducir la latencia, hay compensaciones. Los endpoints geográficos pueden tener diferente disponibilidad de datos o ser menos confiables. Por ejemplo, un nodo en una región con menos pares podría tener mayor latencia de sincronización. Además, el procesamiento por lotes puede aumentar la carga en el nodo, así que úsalo con prudencia.

Las suscripciones requieren mantener una conexión persistente, lo que puede ser más complejo de gestionar. El caché puede llevar a datos obsoletos si no se invalida correctamente. Y los nodos dedicados cuestan más.

Finalmente, recuerda que la latencia RPC es solo una parte de la ecuación. El rendimiento de tu aplicación también depende del tiempo de consenso de la blockchain, el tiempo de bloque y la eficiencia de tu código. Optimiza tu código antes de culpar al RPC.

Para una inmersión más profunda en problemas relacionados, consulta nuestro artículo sobre cómo solucionar errores de tiempo de espera RPC y monitoreo de endpoints RPC.

Próximos pasos: crea un presupuesto de latencia

Ahora que sabes cómo medir y reducir la latencia, crea un presupuesto de latencia para tu aplicación. Decide qué p50 y p99 necesitas, y prueba tus endpoints regularmente. Usa las técnicas anteriores para cumplir tu presupuesto.

Si estás usando OnFinality, puedes aprovechar nuestra red global para obtener acceso de baja latencia a múltiples cadenas. Consulta nuestro precio para opciones dedicadas. Y explora el cómo elegir un proveedor RPC para encontrar los mejores endpoints para tus necesidades.

Recuerda, la latencia es un objetivo móvil. A medida que tu base de usuarios crece o tu aplicación cambia, reevalúa tus endpoints y arquitectura. El monitoreo regular es clave.