Cómo hacer benchmarks de proveedores de RPC para tu flujo de trabajo

Última actualización: 21 de octubre de 20268 min de lectura

Haz benchmarks de proveedores con tu carga de trabajo

La elección de un proveedor de RPC debería basarse en benchmarks propios de tu carga de trabajo. Hacemos benchmarks de proveedores todo el tiempo, incluidos nosotros mismos, y hemos visto a muchos equipos hacer lo mismo. Enviar las solicitudes es la parte fácil. Lo difícil es decidir qué medir y luego construir una prueba con un resultado sobre el que realmente apostarías una decisión.

Por eso pusimos la metodología por escrito y construimos Alchemy rpcbench para ejecutarla: un solo binario que hace benchmarks de cualquier conjunto de proveedores de RPC desde tu propia máquina, con los métodos que tu app realmente llama. La metodología en sí funciona con las herramientas que ya tengas.

Vale la pena medir tres cosas: latencia bajo carga, retraso de bloques y consistencia de datos. Cada una rompe una parte distinta de tu sistema, y un proveedor fuerte en una puede quedarse atrás en otra, así que un puntaje combinado esconde justo la que te importa. Mide lo que tu app realmente llama, desde donde corre.

¿Qué deberías medir al hacer un benchmark de un proveedor de RPC?

Latencia bajo carga, retraso de bloques y consistencia de datos, medidos y reportados por separado.

Dimensión	Qué mide	Cómo medirla
Latencia bajo carga	Qué tan rápido responde un proveedor a medida que sube el volumen	Sube por varias pruebas a tasas de RPS de producción. Lee p95 y p99 en cada una, con las tasas de fallas y de 429 al lado
Retraso de bloques	Qué tan rápido entrega un proveedor los bloques nuevos	Suscríbete a `newHeads` en todos los proveedores a la vez. Registra quién anuncia cada bloque primero, y por cuánto
Consistencia de datos	Si los datos de un bloque se pueden servir en el momento en que se anuncia	En cada head nuevo, pide el bloque, sus logs, sus recibos y sus transacciones. Verifica que coincidan

La consistencia de datos es la que la mayoría de los equipos nunca prueba. Algunos proveedores sirven distintos métodos desde distintos backends, y esos backends no siempre avanzan juntos, así que un proveedor puede anunciar un head nuevo mientras los logs de ese mismo bloque llegan incompletos. Piensa en una biblioteca que actualiza su catálogo antes de que los libros lleguen a los estantes: el catálogo dice que la novedad ya está, y el estante está vacío.

¿Cuál de estas deberías medir primero?

Empieza por la que coincide con lo que tu app hace con los datos. Si actúas sobre bloques nuevos, es el retraso de bloques. Si lees los logs o el estado de un bloque en cuanto llega, es la consistencia de datos. Si no, es la latencia bajo carga. Hemos visto a equipos como Valantis, Aave, RedStone y Struct correr benchmarks que miden cosas distintas.

Si estás construyendo	Mide primero	Qué está en riesgo
Un DEX o un motor de cotizaciones onchain (p. ej., Valantis)	Retraso de bloques, y luego p99 en los `eth_call` que hace tu lógica de precios	Cotizas contra un bloque que ya quedó atrás, o tu cotización llega después de que se cerró el spread
Un protocolo de préstamos con liquidaciones (p. ej., Aave)	Retraso de bloques y consistencia de datos, y luego p99 en tus lecturas de factor de salud y de precios	La liquidación se ejecuta un bloque tarde, o lee una posición antes de que los datos de ese bloque se puedan servir
Un oráculo o un servicio basado en eventos (p. ej., RedStone)	Retraso de bloques y consistencia de datos, y luego p99 en `eth_getLogs` y `eth_call`	Te pierdes el disparador porque los logs llegaron incompletos
Un indexador o el backend de una wallet (p. ej., Struct)	p95 en tu tasa pico, con las tasas de fallas y de 429 al lado	Los backfills se estancan, o los saldos quedan desactualizados mientras la gente opera

Después compara proveedores un método a la vez, porque un proveedor que es más rápido en promedio puede ser más lento en la única llamada que tu app hace más. Esa diferencia es lo que define todo: una cotización que llega después de que se cerró el spread no es una cotización lenta. Es una orden que no se ejecutó.

¿Cómo corres un benchmark de RPC en el que puedas confiar?

Envía solicitudes con un calendario fijo para medir la latencia. El diseño obvio es enviar una solicitud, esperar la respuesta y luego enviar la siguiente, y eso envía menos solicitudes, sin que lo notes, justo cuando un proveedor empieza a tener problemas. Tu prueba afloja en el momento en que debería mantenerse firme, así que la desaceleración que buscabas nunca aparece en los datos. En cambio, envía con un reloj fijo y registra cuánto se atrasa cada envío respecto de él. Cuando tu propia máquina se queda atrás, los números describen tu máquina.

Preparar la ejecución

Regla	Por qué importa
Prueba los métodos que tu aplicación realmente llama y usa el mismo payload en todos los proveedores	Un benchmark solo compara lo que enviaste. Corre cada método solo, a tasa completa, o los costosos nunca juntan una cola estable
Usa una tasa de RPS parecida a la de producción	Proveedores que se ven idénticos a 50 RPS pueden separarse a 300. Vigila también el ancho de banda, porque un rango amplio de `eth_getLogs` satura tu enlace y simula una degradación
Define qué cuenta como éxito	La latencia cuenta solo las solicitudes exitosas, así que fallar rápido no suma puntos. Mide el tiempo hasta el último byte. Mantén los 429 en su propia categoría

Ejecutarla

Regla	Por qué importa
Calienta todos los proveedores de la misma forma	Antes de cada método, para cada proveedor, envía diez segundos a tasa completa y descártalos. Por tiempo, nunca por cantidad de solicitudes: 10 solicitudes a 500 RPS son 20ms de calentamiento
Mantén el calendario y vigila tu propia máquina	Marca la ejecución si el p99 del desfase de envío supera los 5ms en 1.000 muestras. En ese punto estás midiendo tu máquina
Prueba los proveedores uno a la vez	Si los corres juntos, compiten por tu ancho de banda, y el que gana esa competencia parece más rápido. Dale a cada uno su turno y rota el orden entre ejecuciones

El retraso de bloques es la excepción. "Quién anunció primero este bloque" solo tiene sentido si todos los proveedores se observan en el mismo momento, y es un mensaje pequeño por bloque, así que nadie compite por tu ancho de banda.

Leer los resultados

Regla	Por qué importa
Mide la diferencia entre los dos proveedores en solicitudes idénticas. Si esa diferencia podría ser cero de forma plausible, considéralo un empate	Tus datos no separan a proveedores que están dentro de los intervalos de confianza del otro. Con menos de 100 muestras pareadas, no declares ningún resultado
Córrelo dos veces, desde donde corre tu sistema	La latencia depende de la ruta de red entre tú y el proveedor. Correrlo dos veces te muestra cómo se sostiene el rendimiento en distintas condiciones de red

¿Qué es Alchemy rpcbench?

Alchemy rpcbench es un solo binario que ejecuta toda la metodología anterior desde tu máquina, con tus propias claves. Envía solicitudes solo a los endpoints de tu configuración, y el reporte HTML que produce se te envía directamente a ti.

Lo construimos porque poner la metodología por escrito es la mitad fácil. Cada regla anterior lleva días de construir correctamente, y la mayoría son invisibles cuando las haces mal, que es la peor combinación en una herramienta de medición.

Los valores predeterminados son un punto de partida. Una sección workload: los reemplaza por tus propios parámetros y métodos:

yaml

Copied

workload:
- method: eth_call
  params:
    - to: "0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48"  # a contract on your quote path
      data: "0x18160ddd"                                 # and your calldata
    - "$anchor"                                          # the pinned block every provider is asked about

Los pasos de tasa, la duración, el timeout y la ventana de retraso de bloques también son configurables, y una pasada previa calcula el costo de la ejecución en solicitudes, tiempo y ancho de banda antes de que cualquier carga salga de tu máquina. Ese costo está en compute units de Alchemy, así que tómalo como una verificación de tamaño.

Cada ejecución genera un archivo JSON, agregados en CSV y un dashboard HTML autocontenido. No te va a entregar números que no pueda respaldar. Las muestras escasas, un proveedor limitado o una máquina que se quedó atrás se marcan en la parte superior.

Una ejecución que pasa el filtro te da cuatro cosas, en este orden:

Qué obtienes	Qué te dice
El veredicto de validez	Si vale la pena citar esta ejecución. Léelo antes que cualquier otra cosa
Comparaciones	Solo las diferencias lo bastante amplias para sobrevivir al ruido. Los intervalos superpuestos se reportan como empate
Latencia por método	p50, p90, p95 y p99 en cada paso de tasa, con las tasas de éxito, fallas y 429 al lado
Retraso de bloques y consistencia	Quién anunció cada bloque primero, qué tan atrás llegaron los demás, los bloques perdidos y si los datos de cada head se podían servir

Lo que esta metodología no te dice

Una región no dice nada sobre otra. Si tu sistema corre en otro lugar, córrelo desde ahí.
El retraso de bloques es relativo al proveedor más rápido que probaste, no a la punta real de la cadena.
Los métodos corren uno a la vez, así que una ejecución nunca reproduce la mezcla de tu tráfico en vivo.
Una ejecución es un dato. Recomendamos enfáticamente varias ejecuciones para obtener una señal sólida sobre el rendimiento, porque muchos factores pueden afectar una medición, incluidos problemas que afectan a toda la cadena.
La herramienta Alchemy rpcbench es solo para redes EVM y soporta una red por ejecución.

¿Cómo obtienes acceso a Alchemy rpcbench?

Alchemy rpcbench está en alfa privada. Completa este formulario para solicitar acceso.

Y si prefieres construirlo tú mismo con las herramientas que ya tienes, la metodología anterior es todo lo que hace falta. Nos parece bien cualquiera de las dos opciones, siempre que el número sobre el que termines actuando sea uno que produjiste tú.

Preguntas frecuentes

¿Cómo debería comparar proveedores de RPC?

Corre la misma carga de trabajo contra todos los proveedores desde la región donde corre tu sistema, con los métodos que realmente llama. Envía con un calendario fijo, prueba los proveedores uno a la vez y fija un bloque para que todos respondan la misma pregunta. Lee los resultados método por método, con los conteos de fallas y de límites de tasa al lado de cada número de latencia, y luego repite en otro momento. Si prefieres no construir eso tú mismo, contáctanos para obtener acceso a Alchemy rpcbench.

¿Cuál es la diferencia entre latencia de RPC, retraso de bloques y consistencia de datos?

La latencia es cuánto tarda un proveedor en responder una solicitud que enviaste. El retraso de bloques es cuánto tarda en avisarte que existe un bloque nuevo. La consistencia de datos es si los logs, recibos y transacciones de ese bloque se pueden servir en el momento en que lo anuncia. Un proveedor puede ser fuerte en las tres, o fuerte en una y quedarse atrás en otra, y por eso van en columnas separadas.

¿Puedo confiar en los resultados de una herramienta de benchmark creada por un proveedor?

Sí, y no tienes que creernos. Ninguna ruta de código en Alchemy rpcbench se ramifica según el proveedor con el que está hablando, así que los timeouts o reintentos específicos de un proveedor no tienen dónde esconderse. Apunta cualquier agente de programación a tu clon con el prompt de auditoría del README y lo verificará por ti. La herramienta corre en tu máquina, con tus claves, y los resultados nunca salen de tu carpeta de salida.

¿Debería elegir un proveedor de RPC según un único puntaje general de rendimiento?

No. Un puntaje compuesto elige los pesos por ti, y los pesos correctos dependen de tu aplicación. Un indexador que hace backfill del historial y un bot de arbitraje que compite por un bloque casi no necesitan nada en común de un proveedor. Lee la dimensión que coincide con lo que estás construyendo y luego léela método por método.

¿Desde dónde debería correr un benchmark de RPC?

Desde la región donde corre tu aplicación. La latencia de RPC depende mucho de la ruta de red entre el cliente y el proveedor, así que un benchmark corrido desde una laptop, o desde una región de nube donde no despliegas, mide una ruta que tu tráfico de producción nunca toma.

¿Cuánto tarda en correr un benchmark de RPC?

El tiempo de ejecución depende de cómo configures la prueba, pero la configuración predeterminada tarda unas dos horas. Puedes configurar y empezar a correr una prueba en menos de 10 minutos. La configuración que trae Alchemy rpcbench envía 280.000 solicitudes por proveedor en Ethereum, con siete métodos y tres pasos de tasa, en unos 48 minutos, y la ventana de retraso de bloques suma otra hora. Los proveedores se turnan, así que la fase de latencia crece según cuántos pruebes. Reserva una tarde, porque la confianza requiere muestras.

¿Necesito un endpoint WebSocket para hacer benchmarks de proveedores de RPC?

Para la latencia, no. Para el retraso de bloques y la consistencia de datos, sí, porque ambos dependen de eth_subscribe y de la suscripción a newHeads. También necesitas al menos dos proveedores para el retraso de bloques, ya que mide quién anunció cada bloque primero.

¿Qué proveedores de RPC puedo probar?

Cualquier proveedor con un endpoint JSON-RPC de EVM en la cadena que estás probando. Tú aportas las URLs y las claves, y nada en el método ni en la herramienta depende de quién sea el proveedor.

¿Alchemy publica sus propios benchmarks de RPC?

Sí. Nuestra página de benchmarks publica comparaciones continuas de proveedores que puedes leer hoy. Alchemy rpcbench sirve para producir los tuyos, con la carga de trabajo de tu aplicación y desde la región donde corre.

Boletín de Alchemy

Entérate primero de los lanzamientos

Suscríbete a nuestro boletín

Recibe las últimas actualizaciones de productos y recursos de Alchemy

Más de 80,000 suscriptores

Al ingresar tu correo electrónico, aceptas recibir nuestras comunicaciones de marketing y actualizaciones de productos. Reconoces que Alchemy procesa la información que recibimos de acuerdo con nuestro Aviso de Privacidad. Puedes cancelar tu suscripción en cualquier momento.

Fondo de artículos relacionados de la publicación del blog