Alchemy vs QuickNode: un método reproducible para evaluar RPC

Alcance y la decisión que realmente estás tomando

Elegir entre Alchemy y QuickNode es una decisión sobre ajuste operativo, no una puntuación única. Ambos proveedores exponen JSON-RPC sobre HTTPS y WebSocket, ambos ofrecen planes de pago con medición basada en uso y ambos incluyen APIs mejoradas como endpoints de tokens, NFT y trace. Las diferencias que importan en producción suelen ser más estrechas: qué cadenas y profundidades de archivo necesitas, cómo mide cada proveedor métodos costosos como eth_getLogs y debug_traceTransaction, cómo se comportan los límites de tasa bajo ráfagas y qué tan rápido responde el soporte cuando una región se degrada.

Este artículo no clasifica a los dos proveedores. Describe un método de medición que puedes ejecutar en una tarde y luego explica cómo interpretar la salida. Si quieres una recomendación concreta de endpoint para una cadena específica en lugar de una metodología, las respuestas del RPC Assistant son el lugar adecuado para empezar; esta página cubre cómo verificar cualquier recomendación contra tu propio tráfico.

• Supuesto: ya tienes acceso de prueba o de pago a ambos proveedores y puedes emitir solicitudes desde al menos dos regiones.
• Supuesto: conoces tus cinco métodos RPC principales por volumen y tu pico de solicitudes por segundo.
• Fuera de alcance: conjuntos de datos de benchmark propietarios y cualquier afirmación de latencia autopublicada por un proveedor.

Modelo mental: separa la capa de transporte de la capa de producto

Los proveedores RPC gestionados se sitúan entre tu aplicación y una flota de nodos. La capa de transporte es la parte que puedes medir directamente: establecimiento de conexión, tiempo hasta el primer byte, tiempo de respuesta completo, códigos de estado HTTP y objetos de error JSON-RPC. La capa de producto es todo lo que la rodea: paneles, webhooks, endpoints mejorados, SDKs y herramientas de abstracción de cuentas. La mayoría de los artículos comparativos mezclan ambas, lo que hace que el resultado sea difícil de aplicar.

Mantenlas separadas. Evalúa la capa de transporte con llamadas JSON-RPC sin procesar para comparar infraestructura, no la sobrecarga del SDK. Evalúa la capa de producto por separado enumerando qué endpoints mejorados llama realmente tu aplicación y confirmando que cada proveedor los soporta en tus cadenas objetivo. Un proveedor que gana en latencia pero carece de un método de archivo del que dependes no es una opción viable, y un proveedor con herramientas más ricas pero latencia p99 inestable puede fallar igualmente en una carga de trabajo de trading.

Define un perfil de carga de trabajo antes de tocar un endpoint

Un benchmark sin un perfil de carga de trabajo produce números que no se transfieren. Primero escribe la mezcla de solicitudes. Para un panel DeFi típico, la mezcla podría ser 60% eth_call, 20% eth_getBalance, 10% eth_getLogs, 5% eth_getBlockByNumber y 5% lecturas de trace o archivo. Para un indexador, dominan eth_getLogs y las lecturas de archivo. Para una billetera, importan más eth_getTransactionReceipt y eth_getTransactionCount.

Registra las cadenas, las regiones desde las que se conectan tus usuarios y tus solicitudes por segundo pico y promedio. Este perfil se convierte en la entrada tanto del script de benchmark como del modelo de costo posterior. Sin él, terminarás comparando cuotas mensuales nominales que tienen poca relación con tu factura real.

• Métodos principales por volumen de llamadas, con payloads de parámetros representativos.
• Cadenas y redes, incluidos testnets si despliegas allí.
• Profundidad de archivo requerida, si se necesitan lecturas de estado histórico.
• Distribución geográfica de los llamadores y cualquier restricción de residencia de datos.
• RPS pico, duración de ráfaga y latencia p95 y p99 aceptable.

Construye un arnés de latencia ejecutable con curl

Esto te da una distribución aproximada y confirma que la autenticación funciona. No es suficiente para una comparación real porque el arranque del proceso curl domina en latencias bajas. Pasa a un cliente con conexión persistente para la medición real.

for i in $(seq 1 20); do
  curl -s -o /dev/null -w "%{http_code} %{time_total}\n" \
    -X POST "$RPC_URL" \
    -H "Content-Type: application/json" \
    -d '{"jsonrpc":"2.0","id":1,"method":"eth_blockNumber","params":[]}'
done

Mide percentiles con un script de conexión persistente

Ejecuta cada payload al menos unos cientos de veces, repartidas en diferentes momentos del día. Registra la región, la marca de tiempo y el proveedor junto a cada resultado. Si necesitas una visión más amplia de cómo interactúa la selección de endpoint con la elección de cadena, la guía de endpoints RPC multicadena cubre la dimensión de red.

import json, time, statistics, urllib.request

PROVIDERS = {
    "alchemy": "ALCHEMY_RPC_URL",
    "quicknode": "QUICKNODE_RPC_URL",
}
PAYLOADS = [
    {"jsonrpc":"2.0","id":1,"method":"eth_blockNumber","params":[]},
    {"jsonrpc":"2.0","id":2,"method":"eth_getBalance","params":["0x0000000000000000000000000000000000000000","latest"]},
]

def run(url, payload, n=200):
    samples, errors = [], 0
    for _ in range(n):
        body = json.dumps(payload).encode()
        req = urllib.request.Request(url, data=body, headers={"Content-Type":"application/json"})
        start = time.perf_counter()
        try:
            with urllib.request.urlopen(req, timeout=10) as resp:
                data = json.loads(resp.read())
            elapsed = (time.perf_counter() - start) * 1000
            if "error" in data:
                errors += 1
            else:
                samples.append(elapsed)
        except Exception:
            errors += 1
    samples.sort()
    def pct(p):
        return samples[min(len(samples)-1, int(len(samples)*p))] if samples else None
    return {"n": len(samples), "errors": errors, "p50": pct(0.50), "p95": pct(0.95), "p99": pct(0.99)}

for name, url in PROVIDERS.items():
    for payload in PAYLOADS:
        print(name, payload["method"], run(url, payload))

Registra los resultados en una tabla comparativa

El resultado de verificación esperado es un orden estable a través de ejecuciones repetidas. Si el p95 cambia entre proveedores en ejecuciones consecutivas, tu tamaño de muestra es demasiado pequeño o tu región es ruidosa. Aumenta el número de muestras antes de sacar conclusiones y conserva los datos brutos para poder revisarlos después de que un proveedor cambie su infraestructura.

• | Proveedor | Cadena | Región | Método | Muestras | Errores | p50 (ms) | p95 (ms) | p99 (ms) |
• | Alchemy | Ethereum | eu-west | eth_blockNumber | (medido) | (medido) | (medido) | (medido) | (medido) |
• | QuickNode | Ethereum | eu-west | eth_blockNumber | (medido) | (medido) | (medido) | (medido) | (medido) |

Prueba el comportamiento de límite de tasa y errores bajo ráfaga

Ejecuta esto contra ambos proveedores con la misma concurrencia y compara la distribución de códigos de estado. Un proveedor que devuelve 429 limpios con indicaciones de reintento es más fácil de operar que uno que descarta conexiones silenciosamente.

import concurrent.futures, json, urllib.request

def call(url):
    body = json.dumps({"jsonrpc":"2.0","id":1,"method":"eth_blockNumber","params":[]}).encode()
    req = urllib.request.Request(url, data=body, headers={"Content-Type":"application/json"})
    try:
        with urllib.request.urlopen(req, timeout=5) as r:
            return r.status, r.headers.get("Retry-After")
    except urllib.error.HTTPError as e:
        return e.code, e.headers.get("Retry-After")

url = "RPC_URL"
with concurrent.futures.ThreadPoolExecutor(max_workers=50) as pool:
    results = list(pool.map(lambda _: call(url), range(500)))
from collections import Counter
print(Counter(results))

Verifica la cobertura de métodos y archivo en tus cadenas objetivo

La latencia es irrelevante si un método no está soportado. Construye una matriz de cobertura a partir de tu perfil de carga de trabajo: para cada método, confirma el soporte en cada cadena y cada proveedor. Presta especial atención a las lecturas de archivo, los espacios de nombres trace y debug, los límites de rango de bloques de eth_getLogs y el comportamiento de suscripción WebSocket. Prueba cada uno directamente en lugar de confiar solo en la documentación, porque el soporte puede variar según la red incluso dentro del mismo proveedor.

Para capacidad dedicada o de inquilino único, verifica si el proveedor ofrece nodos aislados y en qué regiones; el modelo de nodo dedicado cambia tanto la latencia como el costo. Si tu carga de trabajo abarca muchas cadenas, el directorio de redes te ayuda a confirmar qué redes están disponibles antes de comprometerte con un proveedor.

Traduce las mediciones en un modelo de costo

Ambos proveedores miden el uso, pero las unidades y los multiplicadores difieren. Construye un modelo de costo a partir de tu perfil de carga de trabajo: multiplica el volumen mensual de llamadas de cada método por el peso de ese proveedor para el método, suma las unidades ponderadas y compáralas con las cuotas del plan y las tarifas de exceso. Incluye el volumen de mensajes WebSocket y cualquier llamada a API mejorada por separado, ya que a menudo se facturan en escalas diferentes.

No compares recuentos mensuales nominales de solicitudes entre proveedores. Un plan que incluye una gran cantidad de lecturas baratas puede seguir siendo más caro que un plan más pequeño si tu tráfico está dominado por métodos ponderados. La página de precios RPC muestra cómo estructura OnFinality sus planes, lo que resulta útil como tercer punto de referencia al construir el modelo.

• Unidades ponderadas por mes = suma sobre métodos de (llamadas × peso del método).
• Costo efectivo = precio del plan + max(0, unidades ponderadas − unidades incluidas) × tarifa de exceso.
• Añade el nivel de soporte y los compromisos de SLA como partidas separadas, no mezclados en el costo por solicitud.

Solución de problemas comunes en benchmarks

La mayoría de las comparaciones engañosas provienen de un puñado de errores evitables. Si tus resultados parecen poco plausibles, revisa esto primero.

• Conexiones en frío: la primera solicitud a un nuevo endpoint paga el establecimiento de TLS y conexión. Descarta las solicitudes de calentamiento.
• Efectos de DNS y proxy: los proxies corporativos y las VPN añaden latencia que no tiene nada que ver con el proveedor. Prueba desde un host limpio.
• Diferencias de payload: una etiqueta de bloque latest acierta en caché con más frecuencia que un bloque histórico específico. Mantén los payloads idénticos entre proveedores.
• Muestras pequeñas: menos de unos cientos de muestras por método y región no producirán valores p99 estables.
• Desfase de reloj: usa un temporizador monotónico para el tiempo transcurrido, no marcas de tiempo de reloj de pared.
• Errores silenciosos: una respuesta rápida que contiene un error JSON-RPC no es una muestra exitosa. Clasifica los errores por separado.

Limitaciones y cuándo dejar de medir

Un benchmark es una instantánea. La infraestructura, el enrutamiento y los precios de los proveedores cambian, y un resultado de una semana puede no mantenerse la siguiente. Trata el arnés como una verificación recurrente en lugar de una decisión única, y vuelve a ejecutarlo después de cualquier cambio de plan o incidente. Acepta también que ningún benchmark local reproduce completamente el tráfico de producción: tu aplicación real tiene caché, agrupación y lógica de reintentos que el arnés no tiene.

Si los dos proveedores están dentro del ruido entre sí en latencia y fiabilidad, la decisión debe pasar al ajuste del producto, la capacidad de respuesta del soporte y los términos contractuales. En ese punto, seguir con micro-benchmarks tiene rendimientos decrecientes. Para equipos que quieren una alternativa gestionada con medición predecible, la descripción general del servicio API explica cómo aborda OnFinality el aprovisionamiento de endpoints.

Próximos pasos: operacionaliza la comparación

Convierte el arnés en un trabajo programado que se ejecute semanalmente desde tus regiones principales y almacene los resultados en una tabla de series temporales. Alerta cuando el p95 o la tasa de errores cruce un umbral que establezcas a partir de tu propia línea base. Mantén actualizado el perfil de carga de trabajo a medida que evoluciona tu aplicación y revisa el modelo de costo cada vez que cualquiera de los proveedores cambie su página de precios.

Si todavía estás acotando una cadena o un endpoint específico en lugar de una comparación completa de proveedores, empieza con el RPC Assistant para obtener una recomendación directa y luego valídala con el arnés anterior. Para equipos que construyen un plan de infraestructura más amplio, la guía de alojamiento de nodos blockchain cubre el lado operativo de ejecutar y monitorear nodos.