¿Puedes comparar los proveedores de RPC de Solana en términos de sus límites de velocidad y rendimiento?

Cómo comparar los límites de velocidad de Solana RPC sin adivinar

La mayoría de las comparaciones de Solana RPC se detienen en "solicitudes por segundo". Ese número es real, pero oculta las partes que realmente rompen las aplicaciones en producción: qué métodos se miden, si se permiten ráfagas, cómo se cuentan las suscripciones WebSocket y qué sucede cuando cruzas la línea. Antes de elegir un proveedor, decide cuál de estos tres perfiles coincide con tu carga de trabajo.

• Aplicación interactiva ligera (billetera, panel, unos cientos de usuarios): un endpoint compartido con un límite de solicitudes por segundo suele ser suficiente. Optimiza para un costo predecible y una conmutación por error simple.
• Trabajo de indexación o análisis (rellenos, getSignaturesForAddress, getProgramAccounts): la medición por método o por unidad de cómputo importa más que las RPS brutas, porque las llamadas pesadas consumen una capacidad desproporcionada.
• Servicio de trading o en tiempo real (suscripciones WebSocket, bucles de confirmación ajustados): necesitas saber cómo se facturan las suscripciones y si puedes obtener un nodo dedicado para eliminar la contención del grupo compartido.

Si puedes nombrar tu perfil, el resto de la comparación es mecánico. Si no, comienza midiendo tu mezcla actual de solicitudes: la sección de monitoreo a continuación muestra cómo.

Los modelos de limitación de velocidad que realmente encontrarás

Los proveedores de Solana RPC generalmente miden el tráfico de una de cuatro maneras, y muchos combinan dos.

1. Límite de solicitudes por segundo (RPS). Un techo plano de solicitudes por segundo, a veces con una breve asignación de ráfaga. Simple, pero una sola llamada costosa puede consumir el mismo "espacio" que una barata.
2. Límites por método. Métodos específicos (a menudo getProgramAccounts, getSignaturesForAddress, getTransaction) tienen sus propios techos más bajos porque son costosos de servir.
3. Medición por unidad de cómputo o crédito. A cada método se le asigna un peso de costo; tu plan otorga un presupuesto por segundo o por mes. Este es el modelo más justo para cargas de trabajo mixtas, pero el más difícil de predecir sin herramientas.
4. Límites de conexión y suscripción. Límites en conexiones WebSocket concurrentes, suscripciones por conexión, o ambos. Fácil de pasar por alto hasta que tu feed en tiempo real se cae silenciosamente.

Un proveedor que anuncia un número alto de RPS pero aplica límites estrictos por método puede sentirse más lento que uno con una tasa principal más baja y presupuestos de métodos generosos. Siempre solicita el desglose a nivel de método, no solo el número principal.

Matriz de evaluación de proveedores

Usa esta tabla como lista de verificación cuando hables con cualquier proveedor de Solana RPC, incluido OnFinality. La columna de la derecha es lo que debes hacer con la respuesta.

OnFinality ofrece Solana RPC compartido a través de su página de red de Solana y nodos dedicados de Solana a través de infraestructura de nodo dedicado cuando los límites compartidos ya no son suficientes. Compara eso con otros proveedores usando las mismas filas anteriores para que la decisión sea equivalente.

Cuánto te cuesta cada método de Solana

No todas las llamadas JSON-RPC son iguales. La siguiente tabla agrupa los métodos comunes de Solana según la presión que ejercen sobre un endpoint compartido. Trátala como una guía de planificación, no como una lista de precios fija: los pesos exactos varían según el proveedor.

La conclusión práctica: si tu carga de trabajo está dominada por las tres últimas filas, un endpoint compartido con límites por método te restringirá mucho antes de que lo haga tu techo de RPS. Esa es la señal más clara para evaluar un nodo dedicado.

Mide tu margen real antes de cambiar

No compares proveedores por números de marketing. Mide tu propio tráfico primero, luego compara. Una pequeña sonda que registre latencia y códigos de error te dirá dónde estás realmente.

// Sonda mínima de Solana RPC: latencia + muestreo de errores
const ENDPOINT = "https://solana.api.onfinality.io/public";

async function probe(method, params = []) {
  const start = Date.now();
  const res = await fetch(ENDPOINT, {
    method: "POST",
    headers: { "Content-Type": "application/json" },
    body: JSON.stringify({ jsonrpc: "2.0", id: 1, method, params }),
  });
  const body = await res.json();
  return {
    method,
    status: res.status,
    ms: Date.now() - start,
    error: body.error?.code ?? null,
  };
}

(async () => {
  const calls = [
    ["getLatestBlockhash", []],
    ["getBalance", ["11111111111111111111111111111111"]],
  ];
  for (const [m, p] of calls) console.log(await probe(m, p));
})();

Ejecuta esto contra tu endpoint actual y contra un endpoint candidato en las mismas condiciones. Rastrea tres señales: latencia mediana, la tasa de respuestas HTTP 429 y códigos de error JSON-RPC como -32005 (el nodo está retrasado o limitado). Una tasa creciente de 429 con tráfico constante es la primera señal de que estás cerca de un techo.

Para una verificación manual rápida, una sola llamada curl confirma la conectividad y la forma de la respuesta:

curl -s https://solana.api.onfinality.io/public \
  -X POST -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","id":1,"method":"getHealth"}'

Un endpoint saludable devuelve {"jsonrpc":"2.0","result":"ok","id":1}. Si ves errores aquí, el problema es la conectividad o el propio endpoint, no tu límite de velocidad.

Suscripciones WebSocket y su presupuesto oculto

Las aplicaciones de Solana en tiempo real dependen de las suscripciones WebSocket, y aquí es donde las comparaciones de límites de velocidad suelen fallar. Dos proveedores pueden anunciar las mismas RPS HTTP pero tratar las suscripciones de manera completamente diferente.

• Algunos cuentan cada suscripción contra tu presupuesto de solicitudes; otros cuentan cada mensaje entregado.
• Algunos limitan las conexiones concurrentes; otros limitan las suscripciones por conexión.
• El comportamiento de reconexión importa: si un proveedor cierra conexiones inactivas agresivamente, tu cliente puede volver a suscribirse constantemente y consumir presupuesto.

Cuando evalúes un proveedor, pregunta específicamente cómo se miden accountSubscribe, logsSubscribe y slotSubscribe, y si el endpoint WebSocket comparte presupuesto con HTTP. OnFinality expone transportes HTTP y WebSocket para Solana; los endpoints exactos se enumeran en la página de red de Solana.

Cuándo un endpoint compartido deja de ser suficiente

Hay un punto en el que ajustar tu cliente ya no ayuda y el grupo compartido en sí es la restricción. Vigila estas señales:

• Aparecen respuestas 429 en tu nivel de tráfico normal, no solo durante picos.
• Los trabajos de getProgramAccounts o de relleno fallan o expiran consistentemente.
• Las suscripciones WebSocket se desconectan bajo carga y comienzan los bucles de resuscripción.
• Los límites por método de tu proveedor son más bajos que tu necesidad en estado estacionario para uno o dos métodos.

En ese punto, la comparación cambia de "qué plan compartido" a "compartido vs dedicado". Un nodo dedicado de Solana le da a tu carga de trabajo su propia capacidad en lugar de compartir un grupo, lo que elimina la contención de otros inquilinos. No es automáticamente más barato, así que compáralo con el costo de diseñar soluciones alrededor de los límites compartidos. Consulta Precios de RPC para formas de planes e infraestructura de nodo dedicado para la opción dedicada.

Lista de verificación de migración para cambiar de proveedor de Solana RPC

Si decides mudarte, hazlo de manera controlada en lugar de un corte abrupto.

1. Inventaría tus métodos. Enumera cada método JSON-RPC y suscripción que usa tu aplicación, con el volumen aproximado de llamadas.
2. Mapea el volumen al nuevo modelo de medición. Convierte tu mezcla a las unidades del proveedor candidato (RPS, límites por método o créditos) para comparar de manera equivalente.
3. Ejecuta ambos endpoints en paralelo. Envía un porcentaje del tráfico de lectura al nuevo endpoint y compara latencia y tasas de error.
4. Agrega conmutación por error. Configura un endpoint secundario y cambia ante 429 o errores de conexión en lugar de fallar la solicitud.
5. Vuelve a probar los trabajos pesados. Ejecuta un trabajo de getProgramAccounts o de relleno contra el nuevo endpoint antes de depender de él.
6. Corta las escrituras al final. Mueve el tráfico de sendTransaction solo después de que las lecturas sean estables, y mantén el endpoint antiguo como respaldo brevemente.

Mantén la ventana de ejecución paralela lo suficientemente larga para cubrir un ciclo completo de tráfico, incluida tu hora más ocupada.

Puntos clave

• La limitación de velocidad de Solana RPC rara vez es solo RPS; los límites por método, la medición por unidad de cómputo y los límites de suscripción generalmente deciden lo que puedes ejecutar.
• Los métodos costosos como getProgramAccounts y getSignaturesForAddress son la causa más común de limitación, no el volumen bruto de llamadas.
• Mide tu propia latencia, tasa de 429 y códigos de error JSON-RPC antes de comparar proveedores por números principales.
• Pregunta cómo se miden las suscripciones WebSocket, porque las aplicaciones en tiempo real pueden agotar un plan solo con suscripciones.
• Cuando los límites compartidos se convierten en la restricción, un nodo dedicado de Solana elimina la contención del grupo compartido; compáralo con el costo de diseñar soluciones alrededor de los límites.
• OnFinality proporciona Solana RPC compartido y nodos dedicados de Solana; comienza desde la página de red de Solana, Precios de RPC y la lista completa de redes RPC compatibles.

Preguntas frecuentes

¿Todos los proveedores de Solana RPC usan el mismo modelo de limitación de velocidad? No. Algunos usan un límite plano de solicitudes por segundo, algunos aplican límites por método y otros usan medición por unidad de cómputo o crédito. Muchos combinan dos o más. El modelo importa más que el número principal porque determina cuál de tus llamadas se limita primero.

¿Por qué mi aplicación alcanza los límites aunque mi tasa de solicitudes sea baja? Generalmente porque unos pocos métodos costosos dominan tu uso. Llamadas como getProgramAccounts y getSignaturesForAddress pueden consumir mucha más capacidad de lo que sugiere su recuento de solicitudes, por lo que una tasa general baja aún puede activar límites por método.

¿Las suscripciones WebSocket se cuentan contra el mismo límite que las llamadas HTTP? Depende del proveedor. Algunos cuentan las suscripciones o los mensajes entregados contra tu presupuesto, y otros limitan las conexiones concurrentes. Pregunta antes de comprometerte, especialmente para aplicaciones en tiempo real.

¿Cuándo debo pasar de un endpoint compartido de Solana a un nodo dedicado? Cuando aparecen 429 en niveles normales de tráfico, los métodos pesados fallan consistentemente o las suscripciones WebSocket se caen bajo carga. En ese punto, el grupo compartido es la restricción, y un nodo dedicado le da a tu carga de trabajo su propia capacidad.

¿Cómo pruebo un nuevo proveedor de Solana RPC antes de cambiar? Ejecuta ambos endpoints en paralelo, envía una parte del tráfico de lectura al nuevo y compara latencia, tasa de 429 y códigos de error JSON-RPC. Vuelve a probar tus trabajos más pesados, luego mueve el tráfico de escritura al final con la conmutación por error en su lugar.

¿Puedo usar OnFinality para Solana RPC? Sí. OnFinality ofrece Solana RPC compartido y nodos dedicados de Solana. Consulta la página de red de Solana para endpoints y Precios de RPC para detalles del plan.