Aumenta tu capacidad de throughput sin salir del dashboard

Un lanzamiento, un mint o un backfill de indexado pueden llevar una app más allá de su capacidad de throughput en menos de un minuto. La buena noticia es que en los planes pagos tu equipo ahora puede aumentar esa capacidad por sí mismo, sin hablar con nosotros. Abre la página de Usage en tu dashboard, elige la capacidad adicional que necesitas y confirma. La nueva base se aplica en cuestión de segundos.

Puedes cancelar el add-on desde el dashboard cuando quieras. La capacidad añadida permanece activa durante el ciclo de facturación actual, y luego tu equipo vuelve a su capacidad de throughput base.

¿Qué es la capacidad de throughput?

El throughput es la velocidad a la que puedes enviarnos requests, medida en unidades de cómputo por segundo (CU/s). Medimos el costo total de tus requests en lugar del número bruto de requests, porque cada método de RPC tiene su propio costo en unidades de cómputo según el trabajo que implica atenderlo.

Calcular el requisito de capacidad implica algo más que sumar esos costos. La tabla de costos tiene una columna de CU y una columna separada de Throughput CU, y para algunos métodos ambas difieren, así que una llamada que es barata respecto a tu uso mensual puede seguir siendo costosa respecto a tu throughput. Usa la columna Throughput CU como referencia al dimensionar tu capacidad.

• La capacidad se asigna a nivel de cuenta, no por app. El throughput antes se configuraba por app y ahora se configura en toda tu cuenta, así que el uso combinado de todas las apps de tu equipo cuenta para un solo número. Crear una segunda app no te da más margen.
• Medimos sobre una ventana móvil de 10 segundos. Nuestra documentación de throughput describe un token bucket evaluado en un intervalo de 10 segundos, así que un límite de 10,000 CU/s te da 100,000 unidades de cómputo en cualquier tramo de 10 segundos. Un pico corto pasa, mientras que el tráfico que se mantiene por encima del límite regresa desde nuestra capa de edge como un HTTP 429 (demasiadas solicitudes).

La ventana importa más que el número en sí. Una carga de trabajo puede estar cómodamente por debajo de su límite en promedio y aun así ser limitada en el pico, razón por la cual un 429 suele sorprender al equipo que lo recibe.

¿Cómo funciona la actualización de throughput?

Abre la página de Usage en tu dashboard, busca la sección de throughput y elige Upgrade limit. Necesitas ser billing admin en tu equipo para ver el control. El menú desplegable de capacidad lista cada incremento con su precio mensual al lado, así que ves el costo antes de comprometerte a nada. La misma página muestra un banner cuando el uso reciente del equipo superó tu capacidad de throughput actual, y al hacer clic te lleva directo al flujo de actualización.

Lo que sucede después de confirmar:

• Las actualizaciones se aplican de inmediato y se renuevan mensualmente. La nueva capacidad se aplica en cuestión de segundos tras confirmar.
• Las reducciones surten efecto al final del ciclo de facturación. Si cancelas, la capacidad adicional permanece activa hasta entonces, así que un backfill que se extiende más de lo previsto no se corta de golpe.
• Cuando no queda ningún incremento self-serve completo, el dashboard te indica que contactes a ventas. Nuestro equipo puede configurar un límite de throughput mayor al que ofrece el dashboard como self-serve.

Qué tan lejos puedes llegar depende de tu plan:

Los equipos en pay-as-you-go comienzan con 10,000 CU/s y llegan a 30,000 CU/s por su cuenta, sin contrato Enterprise ni orden de compra. La capacidad inicial de Enterprise se define por contrato, así que la línea base varía según la cuenta. Tu modal de actualización muestra el máximo exacto para tu equipo, y avanzas hacia él en incrementos fijos mientras quepa un incremento completo por debajo.

Así que cualquier valor por debajo de la capacidad máxima self-serve de tu plan es una decisión que tu equipo toma sin nosotros, en menos de un minuto, siempre que quien la tome sea un billing admin.

¿Cuánto throughput necesitas en realidad?

Parte de la tarjeta y el gráfico de pico de throughput en la página de Usage, no del promedio. Los promedios suavizan los picos hasta hacerlos invisibles y te llevarán a elegir un límite que podría fallar en tu próximo lanzamiento.

Trata ese pico como un piso, no como una lectura exacta. Aplicamos el límite sobre diez segundos, pero el gráfico traza promedios de un minuto, así que el pico que en realidad provocó un 429 se aplana dentro del minuto que lo rodea y aparece más bajo de lo que fue. Para saber si esos picos te costaron requests o solo estuvieron cerca, filtra Request Logs por respuestas 429.

Esa diferencia entre las dos ventanas es gran parte del argumento para comprar margen por encima del pico en lugar de igualarlo. El tráfico que alcanzó un pico de 12,000 CU/s una vez eventualmente alcanzará uno mayor, y el margen sale más barato que un incidente.

Los reintentos y más throughput resuelven problemas distintos, así que conviene saber cuál tienes:

• Los reintentos son adecuados para una pequeña fracción de 429s y para flujos que toleran latencia adicional. Nuestra documentación cubre encabezados Retry-After y backoff exponencial exactamente para este caso.
• Más throughput es la respuesta para rutas sensibles a la latencia y para tráfico que se mantiene sostenidamente por encima de tu límite en lugar de superarlo brevemente. Ninguna estrategia de backoff arregla una carga de trabajo que simplemente necesita más capacidad de la que tiene.

Tres tipos de carga de trabajo impulsan la mayoría de las actualizaciones: crecimiento sostenido a medida que una app gana usuarios, backfills de indexado que extraen historial tan rápido como el endpoint lo permite, y eventos programados como airdrops, lanzamientos de tokens y mints. El primero es permanente y los otros dos son temporales, razón por la cual el flujo admite cancelar con la misma facilidad con la que admite comprar.

¿Cuándo deberías hablar con nosotros en su lugar?

El self-serve cubre los casos comunes, no todos los casos. Contáctanos cuando:

• Superaste el máximo self-serve de tu plan y sigues creciendo.
• Quieres negociar el throughput dentro de un contrato en lugar de facturarlo como un add-on mensual.
• Una sola chain, app o método en tu carga de trabajo tiene picos mucho más pronunciados que el resto, así que un throughput personalizado sería más adecuado que una capacidad a nivel de equipo.

Esas son conversaciones sobre volumen y estructura, y nuestro equipo de expertos puede facilitarlas. Comprar 5,000 CU/s de margen para superar un pico es una decisión más pequeña, por lo que vive en el dashboard, donde puedes tomarla según tu propio calendario.

Obtén más throughput en segundos

Aumenta tu capacidad desde el dashboard de Alchemy hoy mismo. Se resuelve con un menú desplegable y se aplica de inmediato, sin cambios de contrato. Si aún no estás en un plan pago, nuestra RPC API comienza gratis y el precio pay-as-you-go no tiene compromiso mínimo, así que la ruta de actualización está abierta desde tu primer día facturable.

Para ver hacia dónde va realmente tu tráfico, Alchemy Monitor reúne volumen de requests, errores y latencia en un solo lugar, y puedes obtener los mismos datos de uso desde el Alchemy CLI.

¿Estás escalando más allá de lo que cubre el self-serve? Habla con nuestro equipo de ventas sobre precios por volumen, y dimensionaremos la capacidad requerida en función del tráfico que realmente esperas.