Skip to main content
AVISO CRÍTICO: Solo para centros de datos de producciónEstas pruebas de latencia están diseñadas exclusivamente para entornos de centros de datos de producción. NO ejecutes estas pruebas en máquinas locales ni con conexiones de Internet residenciales. El ancho de banda local no puede manejar suscripciones intensivas de Solana y producirá resultados sin valor que no reflejan el rendimiento real.
REQUISITO DE COUBICACIÓN: Despliega cerca de tu endpoint de LaserStreamPara obtener mediciones de latencia útiles, debes coubicar tu infraestructura de pruebas en la misma región que el endpoint de LaserStream que elegiste. La distancia de red dominará las mediciones: si haces pruebas desde otro continente, medirás la latencia de la red, no el rendimiento de LaserStream.

Comprender la latencia en sistemas blockchain distribuidos

Cuando trabajas con servicios de streaming de blockchain, medir la latencia se vuelve complejo porque los sistemas distribuidos no tienen un reloj universal. A diferencia de los sistemas tradicionales, donde puedes medir el tiempo de ida y vuelta a un solo servidor, las redes blockchain incluyen varios validadores, y cada uno recibe y procesa la misma transacción en momentos diferentes. El desafío fundamental: Las blockchains como Solana no tienen un concepto de tiempo absoluto. Cada nodo validador del mundo recibe la misma transacción en un momento diferente, y la confirmación depende de que un porcentaje del clúster alcance un consenso. Esto hace imposible medir la latencia de forma determinista en el sentido tradicional.

Niveles de compromiso y prioridades de latencia

Solana ofrece tres niveles de compromiso, cada uno con distintas características de latencia:
  • Procesado: El más rápido, confirmación de un solo validador (~400 ms)
  • Confirmado: Intermedio, confirmación por supermayoría (~2-3 segundos)
  • Finalizado: El más lento, finalización completa de la red (~15-30 segundos)
Para aplicaciones sensibles a la latencia, el nivel de compromiso procesado suele ser el objetivo. Todas las pruebas de esta guía usan el nivel de compromiso procesado, ya que la mayoría de los casos de uso de alta frecuencia priorizan la velocidad sobre la finalidad absoluta.

Tres enfoques para medir la latencia

1. Comparar streams de gRPC en paralelo

El método más confiable: compara dos streams independientes de la misma fuente de datos y mide cuál recibe primero los eventos idénticos. Ventajas:
  • Elimina los problemas de sincronización de relojes
  • Permite comparar el rendimiento relativo
  • Es el más preciso para comparar servicios

2. Comparar la marca de tiempo local con created_at

Confiabilidad moderada: mide la diferencia entre el momento en que tu sistema recibe un mensaje y la marca de tiempo que el servicio LaserStream incorporó en el mensaje. Limitaciones:
  • Solo representa el momento en que LaserStream creó el mensaje internamente
  • No captura los retrasos anteriores a LaserStream
  • Es menos preciso que el método 1 para medir la latencia real de extremo a extremo

3. Análisis de la marca de tiempo del bloque (no recomendado)

No recomendado: compara la hora de recepción local con la marca de tiempo del bloque de Solana. Limitaciones importantes:
  • Las marcas de tiempo de los bloques solo tienen una granularidad de segundos
  • Solana produce bloques cada 400 ms
  • Proporciona muy poca información útil

Requisitos de configuración

Coubicación regional

Para obtener mediciones de latencia útiles, despliega tu infraestructura de pruebas en el mismo centro de datos o región que tu endpoint de LaserStream. Regiones disponibles de LaserStream:
  • ewr: Nueva York, EE. UU. (costa este) - https://laserstream-mainnet-ewr.helius-rpc.com
  • pitt: Pittsburgh, EE. UU. (centro) - https://laserstream-mainnet-pitt.helius-rpc.com
  • slc: Salt Lake City, EE. UU. (costa oeste) - https://laserstream-mainnet-slc.helius-rpc.com
  • ams: Ámsterdam, Europa - https://laserstream-mainnet-ams.helius-rpc.com
  • fra: Fráncfort, Europa - https://laserstream-mainnet-fra.helius-rpc.com
  • tyo: Tokio, Asia - https://laserstream-mainnet-tyo.helius-rpc.com
  • sgp: Singapur, Asia - https://laserstream-mainnet-sgp.helius-rpc.com
Para hacer pruebas en devnet, usa: https://laserstream-devnet-ewr.helius-rpc.com Consulta la documentación de gRPC de LaserStream para obtener instrucciones completas de configuración y pautas para seleccionar un endpoint.

Configuración del entorno de Rust

Todos los scripts de medición usan Rust con Cargo. Configuración básica:
Crea un archivo .env con tus credenciales:
Obtén tu clave de API de Helius en el panel de Helius. LaserStream devnet está disponible en todos los planes. El acceso a mainnet requiere un plan Business o Professional.

Método 1: Comparación de streams en paralelo

Este script establece dos conexiones independientes con distintos endpoints de gRPC y mide cuál recibe primero los mismos mensajes BlockMeta. Este enfoque elimina los problemas de sincronización de relojes mediante tiempos relativos.
Qué mide: La diferencia de rendimiento relativo entre dos servicios de streaming. La diferencia muestra qué servicio entrega primero la misma información del slot. Métricas clave:
  • Diferencia positiva: El primer servicio (YS) es más lento que el segundo (LS); LaserStream es más rápido
  • Diferencia negativa: El primer servicio (YS) es más rápido que el segundo (LS); LaserStream es más lento
  • Media/mediana: Diferencia de rendimiento promedio
  • P95: Diferencia de latencia del percentil 95
Ejecutar la prueba:
Ejemplo de salida:
La salida muestra diferencias de latencia en tiempo real y estadísticas periódicas. Una diferencia media positiva indica que el segundo servicio (LaserStream) entrega los datos de forma sistemáticamente más rápida.

Método 2: Análisis de la marca de tiempo de creación

Este enfoque compara la marca de tiempo created_at incorporada en los mensajes con la hora de tu sistema local al recibirlos.
Limitación importante: Este método solo mide desde que LaserStream creó el mensaje hasta que lo recibiste. No considera ningún retraso anterior entre el evento de blockchain y el procesamiento de LaserStream. Ejecutar la prueba:
Ejemplo de salida:
Este método proporciona información sobre la latencia de red y procesamiento entre LaserStream y tu aplicación, pero debes usarlo junto con el método 1 para realizar un análisis completo.

Prácticas recomendadas para las pruebas de latencia

Principios clave

  • Coubicación: Despliega las pruebas en la misma región que tu endpoint de LaserStream para minimizar la latencia de red
  • Varios métodos: Usa la comparación de streams en paralelo (método 1) como métrica principal y compleméntala con el análisis de marcas de tiempo
  • Monitoreo a largo plazo: Ejecuta las pruebas durante periodos prolongados para capturar distintas condiciones de red y niveles de congestión de la blockchain
  • Análisis estadístico: Céntrate en los percentiles (P95, P99), no solo en los promedios, para comprender la latencia de cola

Interpretar los resultados

  1. Establece una referencia: Ejecuta las pruebas durante al menos 1 hora para establecer el rendimiento de referencia en condiciones normales
  2. Identifica patrones: Busca patrones en los picos de latencia. ¿Se correlacionan con una alta actividad de la blockchain o con la congestión de la red?
  3. Compara percentiles: La latencia P95 suele ser más importante que la latencia promedio para la experiencia del usuario
  4. Monitorea la consistencia: Un rendimiento consistente suele ser más valioso que la latencia mínima absoluta
Recuerda que la latencia de la blockchain es variable por naturaleza debido a los requisitos de consenso de la red. Céntrate en las diferencias de rendimiento relativo y en la consistencia, no en las cifras absolutas.