Logo
Nuevos usuarios de RPC: 35% de descuento el primer mesVer oferta
RPC Assistant

¿Qué proveedores de RPC de Solana ofrecen el mejor rate limiting y niveles de uso?

Resumen

El rate limiting y los niveles de uso determinan cuántas solicitudes por segundo (RPS) o unidades de cómputo puedes enviar a un endpoint RPC de Solana antes de que comience la limitación. La mejor opción depende de tu carga de trabajo: las dApps ligeras pueden usar endpoints públicos compartidos, mientras que los bots de trading de alta frecuencia, los indexadores y las aplicaciones en producción normalmente necesitan un nodo dedicado o un nivel de pago con rendimiento predecible.

Este artículo explica cómo los proveedores de RPC de Solana estructuran los límites de tasa, qué comparar entre los niveles de uso y cómo evaluar opciones como la API RPC compartida de OnFinality o los nodos dedicados de Solana para tu perfil de solicitudes.

El diseño de alto rendimiento de Solana significa que los proveedores de RPC deben equilibrar el volumen de solicitudes con los recursos del nodo. A diferencia de las cadenas estilo Ethereum, donde los tiempos de bloque son predecibles, Solana produce bloques aproximadamente cada 400 ms, y una sola llamada a getProgramAccounts puede devolver megabytes de datos. Eso hace que el rate limiting y los niveles de uso sean una preocupación de primer orden al evaluar proveedores.

Este artículo desglosa cómo se estructuran típicamente los límites de tasa de RPC de Solana, qué comparar entre niveles y cómo emparejar un proveedor con tu carga de trabajo. Está escrito para desarrolladores y compradores de infraestructura que necesitan un rendimiento predecible sin adivinar límites ocultos.

Recomendación rápida: ajusta el nivel a la forma de tus solicitudes

Antes de comparar nombres de proveedores, clasifica tu carga de trabajo. Los límites de tasa de Solana suelen expresarse como solicitudes por segundo (RPS), solicitudes por cada 10 segundos o unidades de cómputo por segundo. El nivel correcto depende menos de la marca y más de tu patrón de solicitudes.

Patrón de carga de trabajoForma típica de solicitudesNivel que suele ajustarse
UI de billetera o dApp ligera< 10 RPS, principalmente getBalance, getLatestBlockhashRPC compartido/público o nivel de pago de entrada
Bot de trading o arbitraje50–500+ RPS, sensible a la latencia, suscripciones WebSocketNodo dedicado o nivel de pago de alto rendimiento
Indexador o analíticagetProgramAccounts, getSignaturesForAddress en ráfagasNodo dedicado con capacidad de archivo y alto presupuesto de CU
Mint de NFT o airdropPicos cortos de sendTransactionNivel amigable con ráfagas y visibilidad de cola
Herramientas de validadorgetSlot, getEpochInfo constanteUn nivel compartido de bajo costo suele ser suficiente

Si tu aplicación cae en la primera o última fila, un endpoint compartido como la API RPC de Solana de OnFinality suele ser suficiente. Si estás en las filas intermedias, planifica un nodo dedicado o un nivel de pago con límites documentados.

Cómo funciona realmente el rate limiting de RPC de Solana

Los proveedores rara vez publican un solo número. En su lugar, combinan varios mecanismos:

  • Solicitudes por segundo (RPS): un límite máximo de cuántas llamadas HTTP puedes hacer por segundo.
  • Unidades de cómputo (CU): un presupuesto ponderado donde los métodos costosos cuestan más. getProgramAccounts podría costar 100 CU mientras que getBalance cuesta 1 CU.
  • Límites de concurrencia: cuántas solicitudes en vuelo puede tener tu clave de API a la vez.
  • Límites de suscripción WebSocket: a cuántas cuentas o programas puedes suscribirte simultáneamente.
  • Permisos de ráfaga: picos a corto plazo por encima del límite en estado estable, a menudo con un tiempo de enfriamiento.

Cuando excedes un límite, el proveedor normalmente devuelve HTTP 429 con un cuerpo de error JSON-RPC. Algunos proveedores descartan silenciosamente los mensajes WebSocket, lo que es más difícil de depurar.

Una respuesta 429 típica se ve así:

{
  "jsonrpc": "2.0",
  "error": {
    "code": -32429,
    "message": "Too many requests"
  },
  "id": 1
}

Si ves esto durante la operación normal, tu nivel es demasiado pequeño para tu carga de trabajo.

Qué comparar entre niveles de uso

No todos los niveles "ilimitados" o de "alto rendimiento" significan lo mismo. Cuando leas una página de precios, extrae estos detalles:

  1. Unidad de límite: ¿El límite está en RPS, CU o ambos? Un nivel de 100 RPS con un presupuesto de 10,000 CU/s se comporta de manera muy diferente a un nivel de 100 RPS sin ponderación de CU.
  2. Restricciones de métodos: Algunos niveles excluyen getProgramAccounts, getSignaturesForAddress o consultas de archivo. Revisa la lista de métodos permitidos.
  3. Soporte de WebSocket: Si dependes de accountSubscribe o logsSubscribe, confirma que el nivel incluya WebSocket y cuántas suscripciones se permiten.
  4. Comportamiento de ráfaga: ¿El proveedor permite picos cortos o el límite se aplica por segundo sin búfer?
  5. Manejo de excesos: ¿El proveedor limita, factura los excesos o encola solicitudes? La cola añade latencia; la limitación causa errores.
  6. Rotación de claves y acceso de equipo: Para equipos, verifica si puedes emitir múltiples claves de API con límites separados.

Una tabla de comparación útil para evaluar proveedores:

Área de evaluaciónQué buscarPor qué importa
Unidad de límite de tasaRPS + ponderación de CU documentadaEvita limitaciones sorpresa en métodos pesados
Cobertura de métodosgetProgramAccounts, archivo, sendTransactionLos indexadores y bots de trading dependen de estos
Límites de WebSocketNúmero de suscripciones y tasa de mensajesLas aplicaciones en tiempo real fallan silenciosamente sin esto
Política de ráfagaVentana de ráfaga documentadaLos picos de mint y airdrop necesitan margen
Comportamiento de excesosLimitar vs. encolar vs. facturarAfecta el manejo de errores y la UX
Opción dedicadaCapacidad de pasar a un nodo privadoElimina la contención del grupo compartido

La página de precios de RPC de OnFinality lista la estructura de niveles actual, y los nodos dedicados están disponibles cuando los límites compartidos no son suficientes.

Notas proveedor por proveedor sobre rate limiting y niveles

Esto no es un ranking. Es un resumen de cómo diferentes modelos de proveedores abordan el rate limiting, para que puedas hacer las preguntas correctas.

OnFinality ofrece una API RPC de Solana compartida con niveles de uso documentados y un camino a nodos dedicados de Solana. El endpoint compartido es adecuado para desarrollo y tráfico de producción moderado, mientras que los nodos dedicados eliminan los límites de tasa del grupo compartido y te dan un endpoint privado. OnFinality también soporta transportes HTTP y WebSocket en Solana, lo cual importa si usas suscripciones.

Endpoints públicos/gratuitos (incluido el RPC público de Solana) normalmente tienen límites de tasa agresivos, sin SLA y sin garantías de WebSocket. Están bien para pruebas pero no para tráfico de producción.

Proveedores de RPC gestionados con precios basados en créditos a menudo miden por unidades de cómputo en lugar de RPS. Esto puede ser más barato para cargas de trabajo ligeras pero más difícil de predecir para indexadores que llaman a métodos costosos.

Proveedores de nodos dedicados te venden un nodo privado, lo que efectivamente elimina los límites de tasa compartidos pero traslada la responsabilidad de monitoreo y escalado a ti o a la capa gestionada de tu proveedor.

Endpoints RPC de exchanges o billeteras normalmente no están disponibles para aplicaciones de terceros, por lo que rara vez aparecen en comparaciones de proveedores.

Al comparar, pide a cada proveedor su documentación de límites de tasa por escrito. Si un proveedor no puede indicar la unidad de límite y el comportamiento de excesos, trátalo como un riesgo.

Probar los límites de tasa antes de comprometerte

Puedes medir tu límite de tasa efectivo con una prueba de carga simple. Comienza con una concurrencia baja y aumenta hasta que veas 429s o latencia creciente.

# Sonda simple de RPS contra un endpoint RPC de Solana
for i in $(seq 1 50); do
  curl -s -o /dev/null -w "%{http_code} %{time_total}\n" \
    -X POST https://solana.api.onfinality.io/public \
    -H "Content-Type: application/json" \
    -d '{"jsonrpc":"2.0","id":1,"method":"getSlot","params":[]}'
done

Ejecuta esto contra tu endpoint candidato y observa las respuestas HTTP 429 o picos de latencia. Para WebSocket, prueba los límites de suscripción por separado:

// Sonda de suscripción WebSocket
const ws = new WebSocket("wss://solana.api.onfinality.io/public-ws");
ws.onopen = () => {
  ws.send(JSON.stringify({
    jsonrpc: "2.0",
    id: 1,
    method: "slotSubscribe"
  }));
};
ws.onmessage = (event) => console.log(event.data);

Si necesitas un endpoint privado, reemplaza la URL con la URL de tu nodo dedicado desde el panel del proveedor.

Cuándo pasar de compartido a dedicado

Los niveles compartidos son rentables hasta que la contención o los límites comienzan a afectar tu aplicación. Considera un nodo dedicado de Solana cuando:

  • Consistentemente alcanzas 429s durante el tráfico pico.
  • Necesitas datos de archivo o getProgramAccounts en alto volumen.
  • Requieres latencia predecible para lógica de trading o liquidación.
  • Quieres suscripciones WebSocket aisladas sin ruido del grupo compartido.
  • Necesitas ejecutar plugins personalizados o versiones específicas del cliente de Solana.

La opción de nodo dedicado de OnFinality proporciona un endpoint privado de Solana con recursos configurables. Para equipos que quieren infraestructura gestionada sin operar validadores, esto suele ser el punto medio entre RPC compartido y autoalojamiento.

Lista de verificación operativa para niveles de RPC de Solana

Una vez que elijas un nivel, implementa estas prácticas:

  • Instrumenta los 429s: registra cada respuesta de límite de tasa con el nombre del método y la marca de tiempo.
  • Cachea agresivamente: getLatestBlockhash, getEpochInfo y los metadatos de tokens cambian lentamente; cachéalos.
  • Agrupa solicitudes: las llamadas por lotes JSON-RPC reducen la sobrecarga HTTP pero aún cuentan para los límites de CU.
  • Usa WebSocket para suscripciones: hacer polling de getAccountInfo en un bucle es la forma más rápida de alcanzar los límites.
  • Configura tiempos de espera y reintentos del lado del cliente: el retroceso exponencial en 429 es más seguro que el reintento inmediato.
  • Monitorea CU por método: si tu proveedor expone métricas, rastrea qué métodos consumen más presupuesto.
  • Planifica la conmutación por error: configura un endpoint secundario en caso de que tu primario esté limitado o degradado.

Para un marco más amplio de selección de proveedores, consulta Cómo elegir un proveedor de RPC.

Puntos clave

  • Los límites de tasa de RPC de Solana suelen ser una mezcla de RPS, unidades de cómputo, concurrencia y límites de suscripción WebSocket.
  • El mejor nivel depende de la forma de tus solicitudes, no solo de tu volumen mensual.
  • Los endpoints compartidos como la API RPC de Solana de OnFinality se ajustan a dApps ligeras y desarrollo; los nodos dedicados se ajustan a cargas de trabajo de alto rendimiento o sensibles a la latencia.
  • Siempre pide a los proveedores documentación escrita de los límites de tasa, incluido el comportamiento de excesos.
  • Prueba los límites con una sonda de carga antes de comprometerte con un nivel.
  • Cachea, agrupa y usa suscripciones WebSocket para mantenerte dentro de los límites.

Preguntas frecuentes

¿Todos los proveedores de RPC de Solana usan las mismas unidades de límite de tasa? No. Algunos usan solicitudes por segundo, otros usan unidades de cómputo, y algunos combinan ambos. Siempre confirma la unidad antes de comparar niveles.

¿Es suficiente un endpoint RPC de Solana gratuito para producción? Los endpoints gratuitos y públicos normalmente tienen límites agresivos y sin SLA. Están bien para pruebas pero son riesgosos para tráfico de producción.

¿Cómo sé si necesito un nodo dedicado de Solana? Si consistentemente alcanzas 429s, necesitas archivo o getProgramAccounts en volumen, o requieres latencia predecible, un nodo dedicado es el siguiente paso.

¿Puedo usar suscripciones WebSocket en un nivel compartido? Muchos proveedores soportan WebSocket en niveles compartidos pero limitan el número de suscripciones. Verifica el límite antes de construir funciones en tiempo real.

¿Qué sucede cuando excedo mi nivel de uso? El comportamiento varía: algunos proveedores limitan con 429s, algunos encolan solicitudes y algunos facturan excesos. Confirma esto antes de comprometerte.

¿OnFinality ofrece endpoints WebSocket de Solana? Sí, OnFinality soporta transportes HTTP y WebSocket para Solana. Consulta la página de la red Solana para detalles del endpoint.

Para opciones de niveles actuales, visita precios de RPC, y explora redes RPC soportadas para ver dónde encaja Solana en tu configuración multicadena.

Base de conocimiento RPC

Detalles RPC relacionados

Nunca te preocupes por la infraestructura nuevamente

OnFinality elimina la carga pesada de DevOps para que puedas construir de forma más inteligente y rápida.

Comenzar