--- title: "Cómo medimos el rendimiento de RPC" description: "Las cifras de benchmarks son fáciles de citar y fáciles de malinterpretar. Esto es exactamente cómo el benchmark público de lecturas EVM de Alchemy mide la latencia, la tasa de éxito, las fallas y los timeouts en condiciones controladas." --- # Cómo medimos el rendimiento de RPC Las [cifras de benchmarks](https://www.alchemy.com/benchmarks) son fáciles de citar y fáciles de malinterpretar. Esto es especialmente cierto en el caso del [rendimiento de RPC](https://www.alchemy.com/overviews/rpc-node). Un gráfico de latencia puede ocultar varias preguntas distintas: dónde se originó la solicitud, qué método se ejecutó, qué payload se envió, qué se consideró éxito, cómo se manejaron los fallos, y si la prueba midió una sola llamada RPC o un flujo de aplicación completo. Construimos nuestro [benchmark público de lectura EVM](https://www.alchemy.com/benchmarks) para hacer visibles esos detalles. El objetivo es mostrar cómo se comparan los proveedores bajo una configuración de prueba controlada y repetible. Nuestro benchmark responde cómo se comparan los proveedores en métodos de lectura JSON-RPC comunes de EVM, en distintas cadenas, regiones y ventanas de tiempo seleccionadas. Estos son benchmarks de infraestructura a nivel de método: una metodología controlada que se ejecuta por separado para cada método, cadena, proveedor y región. Miden solicitudes RPC individuales, no flujos de aplicación completos como cargar el portafolio de una wallet, preparar un swap o consultar el estado de una transacción en varias llamadas. Esa distinción importa: los resultados a nivel de método ayudan a los desarrolladores a comparar el comportamiento de los proveedores, pero no son un modelo completo de ninguna aplicación en producción. ## ¿Qué es el benchmark público de lectura EVM de Alchemy? El [benchmark público de lectura EVM](https://www.alchemy.com/benchmarks) de Alchemy es una prueba controlada que mide cómo responden los proveedores RPC a solicitudes de lectura JSON-RPC de EVM configuradas. Captura la latencia de respuestas exitosas (promedio, p50 y p95), la tasa de éxito y el conteo de solicitudes fallidas, agrupados por proveedor, cadena, método, región y ventana de tiempo. Calculamos la latencia solo a partir de respuestas exitosas. Los intentos fallidos y los timeouts se rastrean por separado, mediante la tasa de éxito y el conteo de solicitudes fallidas. Esto mantiene el benchmark enfocado tanto en velocidad como en confiabilidad, en lugar de tratar cualquiera de las dos métricas de forma aislada. ## Definiciones y reglas de medición Las definiciones, la configuración y las reglas sobre las que se construye el resto de este artículo. Cada fila se desarrolla en las secciones siguientes. ## ¿Qué cubre el benchmark? El benchmark cubre las mainnets de Ethereum, Optimism, Arbitrum, Base y World Chain, y el conjunto público de proveedores incluye a Alchemy, dRPC, Infura y QuickNode. Seleccionamos estos para cubrir las mainnets EVM más usadas y los proveedores RPC que los desarrolladores evalúan con más frecuencia, con margen para ampliar el conjunto con el tiempo. Para un método dado, todos los proveedores reciben la misma solicitud JSON-RPC configurada. Ejecutamos cada prueba desde regiones controladas de AWS ECS: US East, US West, EU Central y AP Southeast. Dentro de una región, todos los proveedores se prueban desde la misma ubicación del runner, porque la distancia de red puede cambiar la latencia. Si probáramos a un proveedor desde Virginia y a otro desde Singapur, el resultado diría tanto sobre geografía como sobre el rendimiento del proveedor. Cada resultado se agrupa por: - Proveedor - Cadena - Método - Región - Ventana de tiempo móvil ## ¿Qué envía el benchmark a cada proveedor? Un método es la operación que se llama, como `eth_getBalance` o `eth_getLogs`. Un payload es la solicitud completa que enviamos para ejercitar ese método, incluidos sus parámetros. La distinción importa porque el rendimiento depende de ambos: una búsqueda simple y un escaneo de rango grande generan una carga muy distinta en un proveedor, y hasta un solo método puede variar según sus entradas. Para un método dado, todos los proveedores reciben el mismo payload JSON-RPC configurado, en una cuenta paga estándar. Esa es la regla de equidad: mismo método, mismos parámetros, misma cadena, misma región, mismo timeout, mismos criterios de éxito, y sin trato especial para ningún proveedor. Hoy eso significa siete pruebas configuradas en la mayoría de las cadenas, y ocho en Ethereum: - `eth_getBalance`: una consulta de balance de cuenta - `eth_getBlockByNumber` en el bloque `earliest`: una lectura de header en el inicio de la cadena - `eth_getBlockByNumber` en el bloque `latest`: una lectura de header en la cabeza de la cadena - `eth_getLogs` en un rango de 1 bloque - `eth_getLogs` en un rango de 10 bloques - `eth_getLogs` en un rango de 100 bloques - `eth_getLogs` en un rango de 1,000 bloques (solo Ethereum) - `eth_getTransactionReceipt`: una consulta de recibo de una sola transacción Algunos payloads se mueven junto con la cadena. Las llamadas que usan la etiqueta de bloque `latest`, por ejemplo, cambian a medida que la cadena avanza. Otras usan entradas históricas fijas: las pruebas `eth_getLogs` de Ethereum usan rangos de bloques históricos configurados para el contrato del token LINK. La combinación es intencional: - Las entradas fijas hacen que partes de la prueba sean repetibles. - Las entradas móviles hacen que partes de la prueba reflejen el estado en vivo de la cadena. - Las entradas históricas fijas pueden ser más fáciles de cachear para los proveedores. El rendimiento de RPC puede variar ampliamente según el método, los parámetros, el rango de bloques, el tamaño de la respuesta, el comportamiento de la caché y el estado de la cadena. Al leer el benchmark, enfócate en el método y los parámetros más cercanos a tu propia carga de trabajo. ## ¿Cómo se mide el rendimiento? Medimos el rendimiento mediante dos señales, cada una responde una pregunta distinta: latencia, qué tan rápido regresan las respuestas exitosas (reportada como promedio, p50 y p95), y tasa de éxito, con qué frecuencia las solicitudes tienen éxito (con el conteo de solicitudes fallidas detrás de ella). Ambas están relacionadas pero son distintas: una respuesta exitosa rápida no es lo mismo que una confiable. Las reportamos una junto a la otra para que ninguna oculte a la otra. ## ¿Cómo se mide la latencia? La latencia es el tiempo medido por el runner de solicitud y respuesta para un POST JSON-RPC exitoso. El temporizador inicia cuando el runner envía la solicitud y se detiene cuando recibe la respuesta. Si un proveedor devuelve una respuesta válida en 120 milisegundos, esa solicitud tiene 120 ms de latencia. Usamos conexiones HTTP precalentadas y reutilizadas. En términos simples, no estamos midiendo los pasos iniciales de configuración necesarios para abrir una nueva conexión, como la búsqueda DNS, el establecimiento de la conexión TCP o el handshake TLS. El runner prepara la conexión primero y luego mide el POST en sí sobre una conexión keep-alive pooled. Eso acerca el número de latencia al tráfico de aplicaciones repetido, donde los clientes suelen reutilizar conexiones. También significa que no debes leer estos números como latencia en frío de la primera solicitud. Solo las respuestas exitosas entran en la distribución de latencia. Si una solicitud hace timeout, devuelve un error HTTP, devuelve un objeto de error JSON-RPC, falla al parsear o tiene un error de red, la contamos como un intento fallido en su lugar. Los timeouts no se tratan como respuestas lentas de 8,000 ms. Los excluimos de la latencia y los contamos en la tasa de éxito, lo que mantiene la latencia enfocada en la velocidad de respuesta y la tasa de éxito enfocada en la confiabilidad. ## ¿Qué es la tasa de éxito? La tasa de éxito es la proporción de solicitudes intentadas que regresaron exitosamente bajo las reglas del benchmark: solicitudes exitosas divididas entre el total de solicitudes intentadas. Una solicitud se cuenta como exitosa solo si ocurre todo lo siguiente: 1. Se completa antes del timeout del benchmark. 2. Devuelve un estado HTTP 2xx. 3. El cuerpo de la respuesta se parsea como JSON. 4. La respuesta JSON-RPC no contiene un objeto `error` no nulo. No usamos reintentos para ocultar intentos fallidos. Cada solicitud intentada tiene una sola oportunidad. Si falla, esa falla se cuenta. ## ¿Cómo maneja el benchmark los timeouts? El runner del benchmark espera hasta 8 segundos a que cada proveedor devuelva una respuesta válida. Si no llega ninguna respuesta válida a tiempo, registramos el intento como un fallo por timeout. El límite de 8 segundos es parte de nuestra configuración de prueba. No lo establece la cadena, y no es el timeout que un proveedor pueda usar internamente. El límite de 8 segundos se aplica hoy a todos los métodos públicos de lectura EVM. Un método específico podría configurarse con un timeout distinto, pero actualmente ninguno lo tiene. ## ¿Qué cuenta como una solicitud fallida? Rastreamos los intentos fallidos por separado de la latencia. Una solicitud se cuenta como fallida si: - devuelve un estado HTTP distinto de 2xx, como 403, 429, 500, 502, 503 o 504 - devuelve un objeto de error JSON-RPC - hace timeout después de 8 segundos - falla a nivel de red, o - falla al parsear como JSON válido Las respuestas de límite de tasa (rate-limit) cuentan como fallos, y nunca usamos reintentos para convertir intentos fallidos en exitosos. Cada fallo reduce la tasa de éxito del proveedor y se suma a su conteo de solicitudes fallidas para ese método, cadena, región y ventana. ## ¿Cómo se definen las métricas? ## ¿Por qué reportar la latencia y la tasa de éxito juntas? Las respuestas rápidas solo importan cuando las respuestas realmente llegan. Un proveedor puede mostrar baja latencia en las solicitudes que tienen éxito mientras hace timeout o falla con más frecuencia, por eso reportamos la latencia junto a la tasa de éxito: la latencia muestra qué tan rápido regresan las respuestas válidas, la tasa de éxito muestra con qué frecuencia regresan en absoluto. Por ejemplo, si enviamos 1,000 intentos y 990 regresan exitosamente antes del timeout de 8 segundos, la tasa de éxito es 99%. Los 10 intentos fallidos no entran en el p50, p95 ni en la latencia promedio; aparecen como fallos de confiabilidad. Esto evita dos malas lecturas: un proveedor con baja latencia pero más fallos no debe juzgarse solo por velocidad, y un proveedor con alta tasa de éxito pero latencia de cola más lenta no debe juzgarse solo por confiabilidad. ## ¿Por qué el benchmark usa una ventana móvil? El benchmark se ejecuta de forma continua. Los métodos públicos comunes de lectura EVM se ejecutan aproximadamente cada 10 segundos, y actualizamos la [página pública del benchmark](https://www.alchemy.com/benchmarks) cada 5 minutos a partir de una ventana móvil de 24 horas. Con disponibilidad total, un método que se ejecuta cada 10 segundos produce cerca de 8,640 intentos por proveedor, método, red y región cada día. Una ventana móvil de 24 horas da a cada cifra pública suficientes muestras para suavizar picos aislados mientras mantiene la página actualizada. Así que lee la página pública como un resumen diario continuo, no como una sola solicitud, una prueba puntual, ni una instantánea momentánea. ## ¿Qué no mide el benchmark? Hoy, el benchmark mide el rendimiento de lectura de un solo método, en caliente, bajo condiciones controladas. No mide: - Flujos de usuario con múltiples llamadas - Transacciones de escritura o envío de transacciones - Comportamiento de WebSocket o suscripciones - Combinaciones de solicitudes específicas de un cliente - Configuración de conexión en frío para la primera solicitud - Todos los proveedores, cadenas, regiones, métodos o formas de payload - El comportamiento exacto de tu propia arquitectura, nivel de tráfico o geografía de despliegue Ese límite es lo que hace útil al benchmark: te indica dónde aplican los números y dónde deberías ejecutar tus propias pruebas específicas de carga de trabajo. Velocidad y confiabilidad son preguntas relacionadas pero distintas: - La velocidad pregunta qué tan rápido regresan las solicitudes exitosas. - La confiabilidad pregunta con qué frecuencia las solicitudes regresan exitosamente. Diseñamos el benchmark para mostrar esa distinción en lugar de reducirla a una sola afirmación de "proveedor más rápido". ## ¿Cómo deberían usar los desarrolladores los resultados? Usa el [benchmark público](https://www.alchemy.com/benchmarks) como punto de partida para evaluar proveedores. Un patrón práctico de lectura: 1. Elige la cadena y el método más cercanos a tu carga de trabajo. 2. Compara la región que mejor coincida con dónde están tus usuarios o tu infraestructura. 3. Mira el p95, no solo el promedio o el p50. 4. Revisa la tasa de éxito junto a la latencia. 5. Si tu carga de trabajo usa payloads distintos, mayor concurrencia, escrituras, WebSockets o flujos con múltiples llamadas, ejecuta un benchmark específico para tu carga de trabajo antes de decidir. Los benchmarks transparentes te ayudan a hacer mejores preguntas. Facilitan ver qué se probó, qué se contó, qué se excluyó y qué partes del resultado importan más para una aplicación real. ## Preguntas frecuentes ### ¿Qué es el benchmark público de lectura EVM de Alchemy? Es una prueba controlada que mide cómo manejan los proveedores RPC las solicitudes de lectura JSON-RPC comunes de EVM. Registra la latencia de respuestas exitosas (promedio, p50, p95), la tasa de éxito y el conteo de solicitudes fallidas entre proveedores, cadenas, métodos y regiones seleccionados, permitiendo a los desarrolladores comparar proveedores bajo condiciones idénticas y repetibles en lugar de afirmaciones de marketing. ### ¿Cómo se mide la latencia de RPC? La latencia es el tiempo de reloj medido por el runner para un POST JSON-RPC y su respuesta sobre una conexión precalentada y reutilizada. El temporizador inicia cuando se envía la solicitud y se detiene cuando llega una respuesta válida. Solo cuentan las respuestas exitosas, así que la latencia refleja la velocidad de respuesta, no la configuración de la conexión ni los fallos. ### ¿Qué cuenta como una solicitud exitosa? Una solicitud tiene éxito solo si regresa dentro del timeout de 8 segundos, devuelve un estado HTTP 2xx, se parsea como JSON y no contiene un objeto de error JSON-RPC. Cualquier otra cosa, incluidos timeouts, errores HTTP y respuestas de límite de tasa, se cuenta como un intento fallido y se excluye de la latencia. ### ¿Cómo maneja el benchmark los timeouts? El runner espera hasta 8 segundos por una respuesta válida. Si no llega ninguna, el intento se registra como un fallo por timeout, no como una respuesta lenta de 8,000 ms. Los timeouts reducen la tasa de éxito pero nunca inflan la latencia, lo que mantiene la velocidad y la confiabilidad como mediciones separadas. ### ¿El benchmark usa reintentos? No. Cada medición es un solo intento. Si ese intento falla, el fallo se cuenta en lugar de reintentarse. Esto mantiene honesta la tasa de éxito, ya que los reintentos ocultarían los fallos intermitentes que las aplicaciones reales realmente experimentan. ### ¿Qué cadenas y proveedores incluye el benchmark? El benchmark público cubre las mainnets de Ethereum, Optimism, Arbitrum, Base y World Chain. El conjunto de proveedores incluye a Alchemy, dRPC, Infura y QuickNode. Cada proveedor recibe la misma solicitud configurada para un método dado, desde la misma región, bajo las mismas reglas de timeout y éxito. ### ¿Qué métodos RPC prueba el benchmark? El benchmark ejecuta siete pruebas de lectura configuradas, construidas a partir de cuatro métodos EVM: `eth_getBalance`; `eth_getBlockByNumber` en los bloques más antiguo y más reciente; `eth_getLogs` en rangos de 1, 10 y 100 bloques; y `eth_getTransactionReceipt`. Ethereum agrega una prueba `eth_getLogs` de 1,000 bloques, para un total de ocho. Cada una usa un payload fijo, de modo que los resultados se mantienen comparables entre proveedores. ### ¿Qué no mide el benchmark? No mide flujos de trabajo de aplicaciones completos, transacciones de escritura, suscripciones WebSocket, combinaciones de tráfico específicas de un cliente, ni la configuración de conexión en frío. Tampoco cubre todas las cadenas, proveedores, regiones, métodos o payloads. Para esos casos, ejecuta un benchmark específico para tu carga de trabajo que coincida con tu propio tráfico. ### ¿Cómo debo leer un número de latencia p95? Lee el p95 así: para este método, cadena, región y ventana de tiempo, el 95% de las respuestas exitosas fueron al menos así de rápidas. Expone el comportamiento de cola que el promedio oculta. Léelo siempre junto a la tasa de éxito, ya que las respuestas rápidas solo importan cuando las respuestas realmente regresan.