Límite de velocidad de RPC de Sui: qué deben verificar los desarrolladores antes de escalar

Diagnóstico rápido: ¿tu aplicación Sui realmente está limitada por velocidad?

Antes de cambiar de proveedor o reescribir tu indexador, confirma que la limitación es la causa real. Los límites de velocidad de RPC de Sui suelen aparecer como una de estas señales:

• Respuestas HTTP 429 Too Many Requests desde el endpoint RPC.
• Objetos de error JSON-RPC con un mensaje sobre límites de solicitudes, cuota o demasiadas solicitudes.
• Picos repentinos de latencia donde las solicitudes aún tienen éxito pero tardan mucho más.
• Fallos parciales: algunas llamadas en un lote tienen éxito, otras son rechazadas.
• Desconexiones de WebSocket o suscripciones bajo carga.

Si solo ves esto durante despliegues, rellenos o picos de tráfico, casi con certeza estás alcanzando un tope de solicitudes en lugar de una falla del nodo. Si ocurren constantemente con volumen bajo, revisa tu clave de API, la URL del endpoint y si estás enviando solicitudes duplicadas por accidente.

Una forma rápida de confirmarlo es registrar el estado HTTP y el cuerpo del error JSON-RPC de cada llamada, y luego contar los fallos por minuto. La siguiente tabla relaciona los síntomas comunes con las causas probables.

Una vez que sepas qué patrón estás viendo, el siguiente paso es decidir si reducir la carga, cambiar cómo llamas a Sui o migrar a una infraestructura con capacidad que coincida con tu carga de trabajo.

Cómo se estructuran normalmente los límites de RPC de Sui

Sui expone una interfaz JSON-RPC, y la mayoría de los proveedores aplican límites en más de una capa. Comprender estas capas te ayuda a predecir dónde encontrarás un obstáculo.

Tasa de solicitudes por clave. El límite más común es solicitudes por segundo (RPS) o solicitudes por minuto (RPM) vinculadas a una clave de API. Los endpoints públicos suelen aplicar esto por dirección IP, lo que significa que un NAT compartido o un ejecutor de CI pueden consumir el presupuesto de todos los que están detrás de él.

Límites ponderados por cómputo. No todos los métodos de Sui cuestan lo mismo. Un simple sui_getLatestCheckpointSequenceNumber es barato. Los métodos que devuelven grandes conjuntos de objetos, historial de transacciones o flujos de eventos consumen más recursos del nodo y pueden ponderarse más o limitarse por separado.

Topes de tamaño de carga útil y respuesta. Las consultas grandes de sui_getEvents u objetos pueden limitarse por tamaño de respuesta o número de resultados, independientemente de la tasa de solicitudes.

Límites de conexión y suscripción. Las conexiones WebSocket, las suscripciones activas y los flujos concurrentes a menudo se limitan por separado de las tasas de solicitudes HTTP.

Límites de ráfaga versus sostenidos. Muchos proveedores permiten ráfagas cortas por encima de la tasa estable, y luego limitan si mantienes ese nivel. Esto es importante para los indexadores que se ponen al día rápidamente y luego quedan inactivos.

Debido a que estos límites varían según el proveedor y el plan, el enfoque práctico es medir tu propio perfil de tráfico y compararlo con los límites documentados para tu endpoint. Si tu proveedor no documenta claramente los límites por método o de suscripción, considera eso como un riesgo al planificar la capacidad.

Mide primero tu perfil de solicitudes real de Sui

No puedes elegir la solución correcta sin saber qué envías realmente. Instrumenta tu cliente para registrar, por método:

• Llamadas por segundo en el pico y en promedio.
• Latencia p50, p95 y p99.
• Tasa de errores por código de estado y código de error JSON-RPC.
• Número de reintentos y cómo los reintentos amplifican la carga.
• Número de suscripciones WebSocket concurrentes.

Una pequeña sonda de monitoreo puede hacer esto visible. Por ejemplo, un script de Node.js que muestrea un método ligero de Sui y registra el estado y la latencia:

// monitor-sui.js
const ENDPOINT = process.env.SUI_RPC_URL; // tu endpoint RPC de Sui

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

setInterval(probe, 1000);

Ejecuta esto desde la misma región que tu carga de trabajo de producción. Si ves respuestas 429 a una tasa que no esperabas, tu límite efectivo es menor de lo que sugiere tu plan, o algo más está compartiendo tu clave.

Para una verificación directa de JSON-RPC desde la línea de comandos:

curl -s -o /dev/null -w "%{http_code} %{time_total}s\n" \
  -X POST "$SUI_RPC_URL" \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","id":1,"method":"sui_getLatestCheckpointSequenceNumber","params":[]}'

Si necesitas un endpoint funcional para probar, comienza desde la página de la red RPC de Sui y usa el endpoint que figura allí para tu entorno.

Reduce la carga antes de cambiar de proveedor

A veces la solución más económica es enviar menos solicitudes y más inteligentes. Estos patrones reducen la presión sobre el RPC de Sui sin cambiar la infraestructura:

• Agrupa en lotes donde la API lo admita. Las solicitudes por lotes JSON-RPC te permiten combinar múltiples llamadas en un solo viaje de ida y vuelta HTTP, lo que puede reducir la sobrecarga por solicitud y ayudarte a mantenerte por debajo de los topes de tasa de solicitudes.
• Almacena en caché datos inmutables. Los checkpoints, las transacciones finalizadas y los objetos históricos no cambian. Almacénalos en caché localmente o en Redis en lugar de volver a obtenerlos.
• Usa suscripciones en lugar de sondeo. Si estás sondeando nuevos checkpoints o eventos cada segundo, una suscripción o un intervalo de sondeo bien ajustado puede reducir drásticamente el volumen de solicitudes.
• Agrega retroceso con jitter. Los reintentos sin retroceso convierten una limitación breve en una sobrecarga sostenida. Usa retroceso exponencial con jitter y un presupuesto de reintentos.
• Separa las rutas de lectura. Dirige los trabajos pesados de análisis o relleno a un endpoint o clave diferente que tu aplicación orientada al usuario, para que una carga de trabajo no pueda dejar sin recursos a la otra.
• Recorta los conjuntos de resultados. Solicita solo los campos que necesitas y pagina las consultas grandes en lugar de extraer todo a la vez.

Estos cambios a menudo otorgan suficiente margen para aplicaciones en etapa temprana. También hacen que tu perfil de tráfico sea más claro, lo que ayuda cuando evalúas capacidad dedicada más adelante.

Cuándo un endpoint Sui compartido deja de ser la opción adecuada

Los endpoints compartidos y públicos son un punto de partida razonable. Se convierten en una restricción cuando tu carga de trabajo tiene alguna de estas características:

• Tasas de solicitudes sostenidas que se acercan o superan el tope de tu plan.
• Uso intensivo de consultas de eventos, consultas de objetos o datos históricos.
• Muchas suscripciones WebSocket concurrentes.
• Requisitos estrictos de latencia para transacciones orientadas al usuario.
• Múltiples equipos o servicios que comparten una clave de API.
• Rellenos e indexadores que compiten con el tráfico de producción.

En ese punto, la decisión no se trata tanto de encontrar un plan compartido más grande, sino de si necesitas capacidad que no se comparta con otros clientes. La infraestructura de nodos Sui dedicada te proporciona un nodo (o conjunto de nodos) aprovisionado para tu carga de trabajo, de modo que tu rendimiento no se ve afectado por el tráfico de otros inquilinos. OnFinality ofrece tanto acceso a la API RPC como opciones de nodos dedicados, para que puedas comenzar con recursos compartidos y pasar a capacidad dedicada a medida que crece tu perfil de solicitudes.

Opciones comparadas: RPC compartido, RPC de nivel superior, nodos dedicados

El servicio de API RPC de OnFinality está diseñado para que los equipos puedan comenzar con endpoints compartidos y pasar a nodos dedicados sin cambiar su patrón de integración. Para obtener detalles actuales del plan, consulta Precios de RPC.

Lista de verificación de preparación para producción de RPC de Sui

Usa esta lista de verificación antes de escalar una carga de trabajo de Sui:

1. Conoce tu RPS máximo por método. No solo el total de solicitudes, sino qué métodos dominan.
2. Confirma por escrito los límites de tu plan. Tasa de solicitudes, pesos por método, topes de carga útil y límites de suscripción.
3. Implementa retroceso y presupuestos de reintentos. Nunca reintentes en un bucle cerrado.
4. Agrega un endpoint de respaldo. Un segundo proveedor o un nodo dedicado reduce el riesgo de punto único de falla.
5. Monitorea los códigos de error continuamente. Alerta sobre la tasa de 429, no solo sobre el total de errores.
6. Separa las cargas de trabajo. Asigna a los indexadores y al tráfico orientado al usuario claves o endpoints diferentes.
7. Prueba la conmutación por error. Simula la falla de tu endpoint principal y confirma que tu aplicación se degrada correctamente.
8. Planifica el crecimiento. Estima el volumen de solicitudes al doble y al quíntuple de tu tráfico actual y verifica si tu plan aún se ajusta.

Si varios de estos puntos no están claros para tu proveedor actual, es una señal para evaluar alternativas. La guía de selección de proveedor de RPC detalla los criterios con más profundidad.

Errores comunes que parecen límites de velocidad

No todas las fallas son limitación. Estos problemas producen síntomas similares:

• Red o endpoint incorrecto. Apuntar un cliente Sui a un endpoint de testnet, o viceversa, produce errores que pueden parecer rechazos.
• Cargas útiles JSON-RPC mal formadas. Un arreglo params faltante o un nombre de método incorrecto devuelve un error, no un límite de velocidad.
• Claves de API expiradas o rotadas. Una clave inválida puede ser rechazada de una manera que se asemeja a la limitación.
• Problemas de reloj o nonce en transacciones firmadas. Los fallos de envío de transacciones a menudo no están relacionados con la tasa de solicitudes.
• Problemas de DNS o TLS. Los errores de conexión intermitentes pueden imitar la limitación bajo carga.

Verifica el código y el mensaje de error JSON-RPC antes de asumir un límite de velocidad. 429 y los mensajes explícitos de cuota apuntan a limitación; los errores de método no encontrado o parámetros inválidos apuntan a errores del cliente.

Puntos clave

• Los límites de velocidad de RPC de Sui generalmente se aplican por clave de API o IP, y a menudo incluyen topes por método o ponderados por cómputo.
• Las respuestas 429, los picos de latencia y las caídas de suscripción son las principales señales de limitación.
• Mide tu perfil de solicitudes por método antes de cambiar de proveedor; los reintentos pueden amplificar significativamente la carga.
• La agrupación en lotes, el almacenamiento en caché, las suscripciones y el retroceso a menudo resuelven la limitación en etapas tempranas.
• Cuando el rendimiento sostenido, las consultas pesadas de eventos o muchas suscripciones superan los límites compartidos, la infraestructura de nodos Sui dedicada es la opción más predecible.
• OnFinality proporciona acceso a la API RPC de Sui y nodos dedicados; consulta redes RPC compatibles y Precios de RPC para obtener detalles actuales.

Preguntas frecuentes

¿Sui tiene un límite de velocidad de RPC incorporado? Sui en sí es una red; los límites de velocidad los aplican los proveedores de RPC y los operadores de nodos que exponen endpoints. Los endpoints públicos suelen aplicar límites por IP, mientras que los proveedores gestionados aplican límites por clave que varían según el plan.

¿Cómo se ve un error de límite de velocidad de Sui? Lo más común es un estado HTTP 429 Too Many Requests, a veces con un cuerpo de error JSON-RPC que describe una cuota o límite de solicitudes. Algunos proveedores devuelven un mensaje de error genérico, así que registra la respuesta completa.

¿Puedo evitar los límites de velocidad usando múltiples claves de API? A veces, pero revisa los términos de tu proveedor. Muchos proveedores agregan límites por cuenta, y distribuir solicitudes entre claves puede violar las políticas de uso. El camino más limpio es reducir la carga o migrar a capacidad que coincida con tu carga de trabajo.

¿Cuándo debería migrar a un nodo Sui dedicado? Cuando tu tasa de solicitudes sostenida se acerca al tope de tu plan, cuando dominan las consultas pesadas de eventos o históricas, cuando ejecutas muchas suscripciones concurrentes, o cuando el tráfico sensible a la latencia comparte un endpoint con trabajos por lotes.

¿OnFinality ofrece RPC de Sui? Sí. OnFinality proporciona acceso a la API RPC de Sui y opciones de nodos dedicados. Consulta la página de la red Sui para detalles del endpoint y Precios de RPC para información del plan.

¿Cómo pruebo si mi aplicación está siendo limitada? Ejecuta una sonda ligera contra tu endpoint desde tu región de producción, registra los códigos de estado y la latencia, y compara el patrón de fallos con tu tasa de solicitudes. Si los fallos se agrupan en el pico de tráfico, la limitación es la causa probable.