--- title: "Rendimiento de Solana gRPC: una metodología de benchmark pública" description: "Cómo medimos la latencia de entrega de Solana gRPC en seis regiones, con resultados p50, p90 y p99, la configuración completa de la prueba y los comandos exactos para reproducirlos." --- # Rendimiento de Solana gRPC: una metodología de benchmark pública Las cifras de rendimiento de Solana son tan útiles como el método detrás de ellas. Una cifra de latencia sin una región, una ventana de tiempo y una configuración de prueba no se puede verificar, comparar ni reproducir. Este artículo documenta cómo medimos nuestros [streams gRPC de Solana](https://www.alchemy.com/solana-grpc), publica las cifras que producen esas mediciones e incluye la configuración completa para reproducir la prueba contra cualquier endpoint, incluido el nuestro. ## ¿Por qué publicar la metodología? Una sola cifra de latencia no dice nada sobre dónde se ejecutó la prueba, a qué se suscribió, con qué nivel de commitment ni en qué ventana de tiempo. En Solana, esos detalles determinan el número: los bloques llegan en menos de un segundo y los márgenes entre endpoints de streaming son de unos pocos milisegundos. Ya publicamos [las reglas de medición detrás de nuestros benchmarks de solicitudes](https://www.alchemy.com/blog/how-we-benchmark-rpc-performance); este artículo hace lo mismo para el streaming de Solana. Cualquiera puede verificar un benchmark de solicitudes enviando la misma solicitud. Un stream es más difícil de examinar. No puedes repetir un momento de actividad de la cadena para ver si tu proveedor lo entregó rápido, completo y en orden. Un método publicado permite a los desarrolladores volver a ejecutar la prueba con su propia carga de trabajo en lugar de confiar en una de las partes. ## ¿Qué mide el benchmark? El rendimiento del streaming son tres preguntas separadas: cuándo llegan los datos, si llegan todos y qué pasa cuando se corta la conexión. Este benchmark responde la primera, por región. - **Ida y vuelta de red (p50).** La mediana del tiempo de conexión TCP desde el runner hasta el endpoint, sobre 30 conexiones. Depende sobre todo de la geografía, así que te indica cuánto cuesta tu ubicación antes de que se mueva cualquier dato. - **Dispersión de entrega (p90, p99).** Cuántos milisegundos después de la entrega más rápida de la ejecución llega un mensaje lento o del peor caso. La cola es lo que siente tu sistema en el peor momento. A un monitor de liquidaciones no le importa que la actualización típica haya sido rápida si la que importaba llegó tarde. Reportamos ambas por región, nunca como un promedio global único. ## ¿Cómo se mide el tiempo de un stream sin confiar en los relojes? Medir el tiempo de una solicitud es fácil. Una máquina la envía y recibe la respuesta, así que un solo reloj cubre todo el viaje de ida y vuelta. Un stream rompe esa comodidad. El evento se origina en un validador, pasa por la infraestructura del proveedor y llega a tu proceso suscriptor en otra máquina, en otro centro de datos. Ahora hay dos relojes involucrados, y los relojes de máquinas separadas pueden diferir varios milisegundos incluso cuando ambos usan NTP. Los márgenes de entrega entre endpoints bien operados pueden ser menores que eso, lo que significa que un cálculo ingenuo con timestamps puede terminar midiendo el error del reloj en lugar del rendimiento. Nuestro endpoint marca cada mensaje con la hora en que se creó, y el runner resta esa marca de la hora en que llega el mensaje. Esa resta compara dos relojes, así que el runner verifica su propio reloj contra un servidor de hora público antes y después de cada ejecución. Aun así, puede quedar un pequeño error fijo. Reportar cada mensaje en relación con la entrega más rápida de la ejecución lo elimina, porque un error fijo del reloj desplaza cada mensaje en la misma cantidad y se cancela en la resta. La columna de ida y vuelta no necesita corrección, ya que el runner mide cada conexión TCP con su propio reloj. Estas cifras no indican el tiempo total desde el validador hasta tu proceso, y no clasifican a los proveedores. Clasificarlos requiere una prueba diferente, dos streams comparados desde la misma máquina, que se cubre en la sección de reproducción. Dos detalles mantienen honesta la medición. El nivel de commitment se fija en `processed`, el nivel de confirmación más temprano, porque mezclar niveles de commitment significa medir puntos distintos en la vida de un evento. Y los timestamps de bloque de la propia cadena quedan completamente fuera del cálculo. Solana produce bloques en [menos de un segundo](https://www.alchemy.com/blog/zero-downtime-zero-gaps-solana-grpc-streaming), mientras que los timestamps de bloque solo tienen resolución de un segundo, así que son demasiado gruesos para ver márgenes de milisegundos. ## ¿Cómo es una ejecución de prueba? Cada cifra de este artículo proviene de una ejecución con la siguiente forma. Cuando cambia la configuración, volvemos a publicar las cifras con una fecha nueva en lugar de editarlas en el mismo lugar. - **Stream bajo prueba:** un solo stream de transacciones gRPC compatible con Yellowstone por ejecución. - **Cuenta observada:** PumpSwap, el programa AMM de Pump, `pAMMBay6oceH9fJKBRHGP5D4bD4sWpmSwMn52FMfXEA`, elegido por su alto volumen de transacciones. - **Nivel de commitment:** `processed` en todas las ejecuciones. - **Tamaño de muestra:** 20,000 transacciones por región. - **Puntos de medición:** runners en máquinas de [Fly](https://fly.io/) en seis regiones cliente: Este de EE. UU., Oeste de EE. UU., Europa Occidental, Europa Central, Singapur y Tokio. El tiempo de ida y vuelta de cada runner hasta el endpoint forma parte de sus resultados, porque un benchmark ejecutado desde una cafetería mide la cafetería. - **Cliente:** el ejemplo `latency` en Rust de geyserbench con la configuración de cliente predeterminada sobre TLS, que se muestra en la sección de reproducción más abajo. - **Ventana de tiempo:** del 14 al 16 de octubre de 2026. Cada tabla publicada incluye las fechas de la ejecución que la produjo. ## ¿Cuáles son los resultados? Comportamiento de entrega de nuestro stream gRPC de Solana, medido desde un cliente en cada región. Cada fila corresponde a 20,000 transacciones en un solo stream con commitment processed, ejecutado del 14 al 16 de octubre de 2026: La columna p50 es la mediana del tiempo de ida y vuelta de red desde el runner hasta el endpoint. Las columnas p90 y p99 muestran cuántos milisegundos después de la entrega más rápida de esa ejecución llega un mensaje lento o del peor caso. Lee el p50 como el costo de distancia de tu ubicación, y el p90 y el p99 como qué tan estable es la entrega. Ninguno es la latencia total de extremo a extremo desde el validador. La forma correcta de dimensionar tus propias expectativas es la fila de tu región: los desarrolladores en Frankfurt deberían leer la fila de Europa Central, no un promedio global sesgado hacia la región que haya resultado más rápida. Cuando [lanzamos Solana gRPC](https://www.alchemy.com/blog/introducing-alchemy-solana-grpc) publicamos una versión temprana de esta afirmación (entrega entre 5 y 15 ms más rápida en promedio que las alternativas, medida desde us-east-1). Esta tabla es la sucesora multi-región de esa instantánea comparativa de una sola región, con una métrica diferente y complementaria. ## ¿Cómo se reproduce? Necesitas Rust y una API key de Alchemy con acceso a Solana gRPC (la [guía de inicio rápido](https://www.alchemy.com/docs/reference/yellowstone-grpc-quickstart) enumera los requisitos previos). Tres comandos: Abre un stream gRPC de Solana, observa 20,000 transacciones en una cuenta con mucha actividad con commitment processed e imprime la mediana del tiempo de ida y vuelta de red hasta el endpoint, y luego cuántos milisegundos por encima de la entrega más rápida llegan tus mensajes p50, p90 y p99. Ejecútalo en un servidor en la región que te interesa y compáralo con la tabla anterior. Usamos `pAMMBay6oceH9fJKBRHGP5D4bD4sWpmSwMn52FMfXEA`, PumpSwap, el programa AMM de Pump. Es una buena opción porque tiene un volumen muy alto, así que 20,000 transacciones llegan rápido. Para observar otro programa o ejecutar una prueba más corta, define `ACCOUNT` con la dirección del programa y `N` con el número de transacciones: Para comparar dos proveedores en lugar de medir uno, ejecuta ambos streams desde la misma máquina y registra cuál entrega primero cada transacción. El [geyserbench](https://github.com/hmstudio-labs/geyserbench) público hace esto desde un solo archivo de configuración que lista ambos endpoints, y reporta con qué frecuencia cada uno detecta primero una transacción. Si ejecutas esto y obtienes cifras sustancialmente distintas de las nuestras, avísanos. Descubrir eso es la razón por la que el método es público. ## ¿Qué no mide este benchmark? Tres cosas quedan fuera de este benchmark de forma deliberada: - **Confiabilidad del stream.** Este es un benchmark de latencia. No mide eventos perdidos, desconexiones, tiempo de reconexión ni backfill después de una reconexión, así que no dice nada a favor ni en contra de esos aspectos. Si tu aplicación depende de una entrega sin brechas, pruébala directamente. Nuestros endpoints conservan 48 horas de historial (más de 400,000 slots) que un cliente que se reconecta puede reproducir con `from_slot`. - **Inclusión de transacciones.** Lograr que una transacción se incluya en un bloque es un problema de la ruta de escritura, con su propia infraestructura y sus propios modos de falla. Nada de lo que hay aquí dice algo al respecto. - **Lecturas de solicitud/respuesta.** Hacer polling a un método JSON-RPC es un patrón de acceso diferente con modos de falla diferentes, y nuestro [benchmark público de RPC](https://www.alchemy.com/benchmarks) cubre el tráfico de solicitudes por separado, con sus propias reglas publicadas. ## Preguntas frecuentes ### ¿Qué tan rápido es Solana gRPC de Alchemy? Depende de dónde midas, y por eso Alchemy publica distribuciones de latencia por región en lugar de una sola cifra global. La tabla regional anterior reporta el tiempo de ida y vuelta de red y la dispersión de entrega p90 y p99, producidos con la metodología publicada en una fecha indicada. El tiempo de ida y vuelta de red hasta el endpoint va de 1.8 ms en el Este de EE. UU. a 21.9 ms en Europa Occidental, y los mensajes p99 llegan entre 6.8 y 23.6 ms después de la entrega más rápida, según la región. ### ¿Cómo se mide la latencia de Solana gRPC? Un cliente en cada región abre un stream gRPC con commitment `processed`, observa 20,000 transacciones en un programa de alto volumen y compara la hora de llegada de cada mensaje con la hora en que nuestro endpoint lo creó. Los resultados se reportan por región como el retraso p90 y p99 por encima de la entrega más rápida de la ejecución, junto con la mediana del tiempo de ida y vuelta de red desde el cliente hasta el endpoint. ### ¿Puedo reproducir los benchmarks de Solana gRPC de Alchemy? Sí. La prueba se ejecuta con el ejemplo `latency` de geyserbench, y los comandos exactos están publicados en este artículo. Ejecútalo en un servidor en la región donde sirves tu aplicación, con commitment `processed`, y compara tus percentiles con la tabla regional. Para comparar dos proveedores, geyserbench también puede ejecutar ambos endpoints lado a lado desde la misma máquina. ### ¿Qué nivel de commitment usan los benchmarks? Cada ejecución se suscribe con `processed`, el nivel de commitment más temprano de Solana. Mezclar niveles de commitment mediría eventos en puntos distintos de su ciclo de vida, lo que haría que los percentiles no tuvieran sentido. Tu aplicación en producción puede preferir `confirmed` o `finalized`; la metodología mantiene constante el commitment para que las cifras sigan siendo comparables entre regiones y ejecuciones. ### ¿Es una comparación con otros proveedores? No. Este artículo documenta cómo Alchemy mide y publica el rendimiento de su propio Solana gRPC. Otros proveedores publican sus propios benchmarks, y que haya más metodología publicada en esta categoría es bueno para todos. La sección de reproducción existe para que tú mismo puedas ejecutar la comparación que importa, con tu carga de trabajo. ## Empieza a transmitir datos de Solana Nuestro [streaming gRPC de Solana](https://www.alchemy.com/solana-grpc) es compatible con Yellowstone, así que apuntar un cliente existente hacia él es un cambio de URL, no una reescritura. El precio es de $75 por TB, sin mínimo mensual, y la [documentación de Yellowstone gRPC](https://www.alchemy.com/docs/reference/yellowstone-grpc-overview) cubre la guía de inicio rápido. Los equipos que construyen en Solana también pueden postular para obtener hasta $25k en créditos a través del [Fondo de $20M para Solana](https://www.alchemy.com/solana-20m-fund). Si quieres, ejecuta primero el benchmark. Para eso existe.