Rendimientop50p95p99
Distribución de velocidad
Qué tan rápido responde el endpoint en solicitudes normales y de cola lenta.
Volver al benchmarkRendimiento 
Métodos
Límites
Fiabilidad
Producción
Metodología del RPC Benchmark
Esta página explica exactamente cómo se ejecuta el benchmark, qué señales se miden, cómo se generan los veredictos y qué significan y qué no significan los resultados.
En la práctica, el rendimiento de un endpoint depende del routing del proveedor, la actualización de los datos de la cadena, el comportamiento bajo solicitudes repetidas, el estado de caché y la limitación de tasa. Este benchmark aísla esas señales con una comparación corta, desde un mismo servidor y solo para mainnet.
Señales del benchmark
Qué mide este benchmark
Un mapa rápido de las señales detrás de cada resultado: velocidad, estabilidad, soporte por método, throttling, freshness y riesgo de producción.
RendimientoMétodoseth_blockNumber98%
eth_getLogs74%
Desglose por método
Rendimiento, compatibilidad y fallos por método.
Límites 429
Detección de limitación de tasa
Detecta throttling antes de que se convierta en un problema real de tráfico en producción.
Fiabilidad0.8%
Errores
1.2%
Timeout
JTR
Estabilidad
Comportamiento ante fallos
La tasa de timeouts, los tipos de error y la consistencia se agrupan en una sola lectura de fiabilidad.
ProducciónTu RPC
18.4M
GetBlock
18.4M
Actualización y preparación
La actualización de bloque, el desfase de sincronización y la preparación para producción convierten métricas crudas en una decisión.
Reglas principales
Mismas condiciones para ambos endpoints
Tu endpoint y la referencia de GetBlock se prueban desde el mismo servidor de benchmark, en la misma ventana temporal, con el mismo timeout y la misma secuencia de solicitudes generada. El backend selecciona el endpoint baseline de GetBlock según la región del servidor que ejecuta el benchmark, no según la ubicación del navegador del visitante; si ese endpoint regional no está disponible, el reporte marca la región fallback en los metadatos. Cada método muestreado para tu endpoint también se envía a GetBlock, lo que mantiene alineados el mix de métodos y el número de solicitudes. Esto mantiene la comparación justa, pero también significa que la herramienta no es un benchmark sintético multi-región.
Se requiere protocolo mainnet coincidente
La herramienta pública solo compara endpoints mainnet. Una ejecución es válida únicamente cuando el endpoint pegado pertenece al protocolo seleccionado en mainnet, por ejemplo Ethereum mainnet vs GetBlock Ethereum mainnet. Los endpoints testnet y devnet se bloquean porque producirían resultados engañosos de latencia, freshness y comportamiento por método contra una referencia mainnet.
Solo solicitudes de lectura
El benchmark usa exclusivamente llamadas JSON-RPC de solo lectura. Nunca solicita claves privadas, seed phrases, secretos de wallet, firma de transacciones ni métodos de escritura. El objetivo es probar velocidad y fiabilidad sin generar efectos on-chain.
Benchmark corto y puntual
La ejecución es intencionalmente corta. Está pensada para revelar diferencias claras de latencia, fiabilidad, compatibilidad, throttling y freshness, no para certificar un SLA ni predecir capacidad exacta de producción.
Medición de latencia
Cómo se mide la latencia de cada solicitud
Medida desde el servidor de benchmark
La latencia se mide en el servicio backend del benchmark, no en el navegador del visitante. El temporizador empieza justo antes de enviar la solicitud HTTP RPC desde el servidor de benchmark y termina después de recibir y parsear la respuesta.
Tiempo de respuesta round-trip
El valor medido es el tiempo RPC round-trip: ida desde el servidor de benchmark hasta el proveedor, procesamiento del proveedor y vuelta de la respuesta. Solo representa lo que vería tu app si se ejecutara desde una región similar.
La latencia exitosa se separa de los fallos
Solo las muestras exitosas se usan para p50, p95, p99, latencia media, jitter y latencia máxima. Las solicitudes fallidas se cuentan por separado en tasa de error, tasa de timeout, compatibilidad de métodos y hallazgos.
Mismo número de solicitud, mismo método
Ambos endpoints reciben la misma secuencia generada. Si la solicitud #18 es `eth_getBlockByNumber` para tu endpoint, la solicitud #18 también es `eth_getBlockByNumber` para GetBlock. Este modo emparejado mantiene la comparación método por método.
Perfiles y métodos
Cómo “What are you building?” cambia la prueba
El perfil seleccionado cambia el mix de métodos de solo lectura y sus pesos. No da ventaja a ningún proveedor: la secuencia generada es compartida, por lo que tu endpoint y GetBlock reciben los mismos métodos, parámetros, timeout y número de solicitudes.
General dApp
Lecturas ligeras equilibradas para tráfico común de dApps frontend y backend.
eth_blockNumbereth_getBlockByNumbereth_getBalanceeth_call
Wallet / portfolio app
Prioriza balances, bloques recientes y lecturas ligeras de contratos o cuentas.
eth_getBalanceeth_calllatest block readsSolana balance reads
Data indexer / analytics
Enfatiza lecturas intensivas de bloques y logs necesarias para indexadores y analítica.
eth_getBlockByNumbereth_getLogsblock height readsmethod compatibility checks
DEX / trading bot
Se enfoca en estado fresco, baja latencia de cola y métodos que los flujos de trading llaman repetidamente.
eth_blockNumbereth_callfresh state readslatest block / slot
NFT marketplace
Prueba patrones de lectura tipo NFT donde el soporte de métodos y la consistencia importan más que una sola latencia media.
eth_calleth_getLogsmetadata-related readscollection state reads
El soporte por protocolo importa. Las cadenas EVM pueden usar métodos de contratos y logs, Solana usa métodos JSON-RPC de Solana, Tron usa lecturas JSON-RPC compatibles con EVM y los protocolos tipo Bitcoin usan métodos seguros de estado y altura. Si un método no puede generarse de forma segura para un protocolo, se omite.
Flujo del benchmark
1. Validación de entrada y comprobaciones de seguridad
- Solo se permiten URLs RPC con `http` y `https`.
- La herramienta bloquea localhost y rangos privados o internos comunes como `127.0.0.1`, `10.0.0.0/8`, `172.16.0.0/12`, `192.168.0.0/16` y `169.254.0.0/16`.
- El endpoint pegado se comprueba contra el protocolo seleccionado en mainnet antes de iniciar la ejecución. Los endpoints tipo EVM se comprueban con `eth_chainId`; Solana usa `getSlot`; los protocolos tipo Bitcoin usan `getblockcount`; otros protocolos soportados usan el método seguro de identidad o estado disponible.
- Se requiere verificación de Cloudflare Turnstile antes de iniciar el benchmark público. Esto protege la API del benchmark contra abuso automatizado sin exigir registro.
- Si el endpoint informa un protocolo diferente o una red que no es mainnet, el benchmark se bloquea antes de comenzar.
- Se admiten endpoints privados con API keys en la URL. Para almacenamiento y reporting, la herramienta nunca guarda la URL completa en texto plano: solo una versión enmascarada y un hash SHA-256.
2. Fase de warm-up
- Después de la validación, tanto el endpoint del usuario como el de GetBlock reciben una solicitud inicial de warm-up antes de comenzar el muestreo temporizado.
- Las solicitudes de warm-up se usan para reducir el ruido inicial y acercar la medición al comportamiento que una aplicación real ve después de la primera solicitud.
- El warm-up no forma parte del resultado del benchmark. Su función es separar efectos de configuración como DNS, TLS o sobrecoste de la primera solicitud del bucle de medición temporizada.
3. Selección del perfil de solicitudes
- El benchmark selecciona métodos usando una elección aleatoria ponderada. El developer profile elegido controla qué métodos se usan y con qué frecuencia aparecen.
- Los perfiles soportados por el motor son `general`, `wallet`, `indexer`, `trading` y `nft`. En la UI aparecen como General dApp, Wallet / portfolio app, Data indexer / analytics, DEX / trading bot y NFT marketplace.
- En cadenas EVM, el perfil puede incluir métodos como `eth_chainId`, `eth_blockNumber`, `eth_getBlockByNumber`, `eth_getBalance`, `eth_call` y en algunos perfiles `eth_getLogs` con un rango seguro y acotado.
- Para Solana, el perfil puede incluir `getHealth`, `getSlot`, `getLatestBlockhash` y `getBalance`.
- Para Bitcoin, Tron y otros protocolos no EVM soportados, el benchmark usa métodos seguros y de solo lectura apropiados para cada protocolo y omite métodos que no se puedan generar de forma segura.
4. Bucle de muestreo temporizado emparejado
- Durante la ejecución, el motor crea una secuencia compartida de solicitudes a partir del perfil ponderado seleccionado.
- Para cada elemento de esa secuencia, el mismo método de solo lectura y los mismos parámetros se envían a tu endpoint y al endpoint de GetBlock. Las dos llamadas se ejecutan como un par, por lo que ambos proveedores reciben el mismo mix de métodos y el mismo número de solicitudes muestreadas.
- Si un proveedor devuelve error, timeout o limitación de tasa, el sample emparejado se conserva igualmente. Así el número de solicitudes permanece alineado y ningún endpoint recibe una carga diferente.
- El motor sigue enviando solicitudes emparejadas hasta que se alcanza el tiempo límite. Cada sample registra proveedor, método, marca temporal, latencia, estado de éxito, código de estado y clasificación del error.
- Este benchmark está diseñado para comparar el comportamiento de endpoints bajo un bucle de muestreo corto y estable, no para simular un generador de carga altamente paralelo.
- El request rate observado que aparece en la UI es por tanto el tráfico realmente generado en esta ejecución, no un número garantizado de capacidad máxima.
5. Clasificación de latencia y errores
- Para cada solicitud, la latencia empieza justo antes de la llamada `fetch()` y termina inmediatamente después de recibir y parsear la respuesta HTTP.
- Una solicitud solo se marca como exitosa si la respuesta HTTP es OK y el cuerpo JSON-RPC no contiene un campo `error`.
- Una solicitud se marca como timeout si supera el tiempo configurado y se dispara la señal de abortado.
- Una solicitud se marca como error cuando hay errores JSON-RPC, JSON inválido, fallos de red, errores de autenticación y otros fallos distintos de timeout.
- Los HTTP 429, 401 y 403 se conservan como señales diferenciadas porque importan para el diagnóstico de producción.
Señales medidas
Latencia media
La latencia media es la media de las latencias exitosas. Es útil, pero puede ocultar outliers lentos. Por eso el informe también enfatiza la latencia de cola.
Latencia p50
La latencia p50 es la mediana de las latencias exitosas. La mitad de las solicitudes exitosas son más rápidas que este número, y la otra mitad son más lentas.
Latencia p95
La latencia p95 muestra el tiempo de respuesta bajo el cual cae el 95% de las solicitudes exitosas. Es uno de los números más útiles para la experiencia real de usuario porque captura la cola lenta pero frecuente.
Latencia p99
La latencia p99 muestra el borde más lento del comportamiento exitoso normal. Si p99 se dispara mientras la latencia media parece correcta, los usuarios aun así pueden experimentar tiempos de carga inconsistentes.
Tasas de éxito, error y timeout
La tasa de éxito es la proporción de todas las solicitudes muestreadas que terminaron correctamente. La tasa de error es la proporción que falló por cualquier motivo. La tasa de timeout es la proporción que no terminó antes del timeout del benchmark.
Jitter y consistencia
La desviación estándar de latencia y el jitter ayudan a describir la consistencia. En esta herramienta, el jitter se calcula como `p95 - p50`, lo que da una señal simple de dispersión de cola. Una mediana baja con jitter alto suele significar que el endpoint es rápido a veces, pero no de forma predecible.
RPS observado
El RPS observado se calcula como `requestCount / durationSec`. Describe cuánto tráfico generó realmente este benchmark. No debe interpretarse como un límite contractual de throughput ni como un resultado de prueba de carga listo para producción.
Lógica del veredicto
Veredictos por método
Los veredictos por método comparan el mismo método en ambos proveedores. Si un lado tiene cero respuestas exitosas mientras el otro sí responde, el método se marca como fallido en ese proveedor. Si un lado presenta una alta tasa de error o timeout, el método se marca como inestable. En otros casos, la latencia p95 decide el ganador, salvo que la diferencia sea inferior al 10%, en cuyo caso el método se marca como similar.
Puntuación del proveedor
Los scores combinan latencia media, p95, p99, tasa de éxito, timeout y freshness adaptada al protocolo. El score es sensible a la latencia, pero la fiabilidad sigue pesando: un endpoint muy rápido con muchas llamadas fallidas no debería parecer listo para producción. El score no es un estándar del protocolo; es una señal compacta de comparación usada por esta herramienta.
Etiqueta de preparación para producción
Las etiquetas de preparación para producción se eligen a partir de los resultados medidos. Algunos ejemplos son problemas de compatibilidad de métodos, riesgo de nodo desactualizado, alto riesgo de timeout, posible limitación de tasa, rápido y estable, lento pero fiable y rendimiento similar. La etiqueta resume lo que es más probable que falle en el uso real.
Hallazgos accionables
Los hallazgos accionables se generan a partir de evidencia concreta del benchmark y en el informe siguen una estructura Problema → Por qué importa → Qué hacer después. Respuestas HTTP 429 repetidas generan un hallazgo de limitación de tasa, 401/403 generan un hallazgo de acceso, una alta tasa de timeout genera riesgo de timeout, los fallos por método generan hallazgos de compatibilidad, el jitter alto genera un hallazgo de consistencia y el retraso de bloque genera un hallazgo de actualización.
Reglas de freshness
Cómo se detecta el sync lag
- Para endpoints tipo EVM y Tron, el benchmark compara el último número de bloque cerca del final de la ejecución.
- Para Solana, compara el último slot cerca del final.
- Para protocolos tipo Bitcoin y otros protocolos no EVM soportados, compara la altura, slot, ledger o valor de estado más reciente y seguro que devuelva el protocolo.
- La diferencia de altura se convierte en retraso temporal estimado usando la cadencia nominal configurada para el protocolo seleccionado. En cadenas rápidas, un bloque de diferencia puede ser menor; en cadenas lentas como Bitcoin, un bloque puede ser un retraso significativo.
- Una diferencia equivalente a no más de 6 segundos se considera similar. Así, un bloque en una red rápida es una variación menor, mientras que un bloque de Bitcoin es un retraso importante.
- La puntuación de freshness disminuye con el retraso temporal estimado y aporta el 10 % del score del proveedor. Si el endpoint del usuario supera la tolerancia, se marca como stale node risk.
Limitaciones
Qué no afirma este benchmark
- Este no es un benchmark geográfico. La herramienta pública se ejecuta actualmente desde un solo servidor de benchmark, no desde múltiples probes globales.
- Esta no es una prueba de alta concurrencia. La herramienta mide comportamiento comparativo bajo un bucle automatizado corto de solicitudes, no bajo una reproducción completa de tráfico de producción.
- El rendimiento puede cambiar según el origen de las solicitudes, cómo enruta el proveedor el tráfico, si la caché está caliente y cuánta carga tiene la infraestructura del proveedor en ese momento.
- Los endpoints públicos pueden verse bien durante unas pocas solicitudes y luego degradarse, hacer timeout o aplicar limitación de tasa. Repetir el benchmark en otro momento suele ser útil.
- La caché, el plan del proveedor, la congestión temporal de red y el routing del backend pueden cambiar los resultados entre ejecuciones.
- El benchmark público es solo para mainnet. Los endpoints testnet y devnet necesitan referencias separadas y no deben mezclarse con resultados de comparación mainnet.
- El benchmark enmascara la URL RPC del usuario antes de almacenarla y solo conserva valores enmascarados o derivados en la metadata devuelta a la UI.
