ForHosting KIT · Utilidades de desarrollo

Servidores necesarios para una carga con margen de seguridad

La calculadora de servidores necesarios convierte una previsión de tráfico en un objetivo práctico de escalado horizontal.

● BetaGratis · en su navegador
Úselo desde WebAPIEmailTelegramApp pronto

Introduzca la tasa máxima de solicitudes, la capacidad medida de un servidor y el porcentaje que desea reservar como margen de seguridad. La herramienta reduce la capacidad útil de cada servidor, divide la carga objetivo por ese valor y redondea hacia arriba. También muestra la capacidad provisionada, la capacidad útil, la reserva restante y la utilización prevista para que usted pueda revisar cada supuesto.

Parta de una carga objetivo y una capacidad medidas

Un dimensionamiento fiable exige mediciones compatibles. Introduzca como objetivo la mayor tasa sostenida que deba atender el despliegue, no un promedio diario que oculte las horas punta. Obtenga la capacidad por servidor mediante una prueba representativa con la misma versión de la aplicación, tipo de instancia, mezcla de solicitudes, dependencias y objetivo de latencia previstos para producción. Ambos valores deben expresarse en solicitudes por segundo. Si un servidor solo alcanza una cifra superior incumpliendo el nivel de servicio, no utilice esa cifra. La calculadora admite un objetivo cero, pero la capacidad del servidor debe ser positiva. Considere el resultado una base de planificación: bases de datos, colas, cachés, conexiones, servicios externos y solicitudes lentas pueden limitar el sistema antes que los servidores de aplicación. Repita el cálculo cuando cambien la carga o las mediciones.

Reserve margen para no operar al límite

El margen de seguridad es el porcentaje de la capacidad medida que se mantiene libre en cada servidor. Con un margen del 25 por ciento, un servidor capaz de procesar 1.200 solicitudes por segundo aporta 900 al cálculo. Esa reserva absorbe ráfagas, errores de previsión y el tiempo necesario para iniciar nuevas instancias, además de reducir el riesgo de que la latencia aumente cerca de la saturación. El porcentaje adecuado depende del comportamiento operativo. Un servicio interno estable y con arranque rápido puede usar menos margen; una API pública con tráfico irregular, calentamiento lento o latencia estricta puede necesitar más. Introduzca un valor desde cero y menor que 100. La herramienta aplica el margen antes de dividir y redondea siempre hacia arriba, por lo que la flota resultante cubre al menos la carga declarada. Compare varios márgenes para hacer visible el equilibrio entre resiliencia y coste.

Convierta el resultado en una decisión de provisión

El resultado principal es el número mínimo entero de servidores idénticos cuya capacidad ajustada alcanza el objetivo. La capacidad útil por servidor refleja la reserva aplicada. La capacidad provisionada representa el rendimiento nominal completo de la flota, mientras que la capacidad útil provisionada indica cuánto permite consumir el plan. La capacidad útil sobrante aparece porque el número final se redondea hacia arriba. La utilización compara la carga objetivo con la capacidad nominal total. Use estos datos para documentar un mínimo de autoescalado, una flota fija o un presupuesto de infraestructura, y después valide la topología con pruebas de carga y fallos. La alta disponibilidad, la distribución por zonas, el mantenimiento, las réplicas o la pérdida de una instancia pueden exigir más servidores que el mínimo de rendimiento. La calculadora no añade esa redundancia automáticamente; aplique después sus requisitos arquitectónicos y repita el análisis cuando cambien las instancias o el rendimiento de la aplicación.

Definir una base de autoescalado

Convierta el pico previsto y el rendimiento medido en un mínimo justificable de instancias con reserva explícita.

Comparar tipos de instancia

Calcule el mismo objetivo con capacidades medidas de varios tamaños de servidor antes de provisionar.

Documentar una revisión de capacidad

Registre objetivo, medición, margen, utilización y capacidad sobrante que sustentan la decisión.

¿Cómo se calcula el número de servidores?

La capacidad útil es la capacidad por servidor multiplicada por uno menos el porcentaje de margen. Se divide la carga por ese valor y se redondea hacia arriba.

¿Qué capacidad por servidor debo indicar?

Use el rendimiento sostenido de una prueba representativa que respete sus objetivos de latencia y errores, con una configuración similar a producción.

¿El margen implica servidores adicionales?

El margen reduce la capacidad atribuida a cada servidor y puede aumentar la flota redondeada. La reserva cubre ráfagas, arranques y errores de previsión.

¿El resultado incluye redundancia de alta disponibilidad?

No. Solo calcula el mínimo por rendimiento. Añada las instancias necesarias para zonas, mantenimiento, réplicas, cuórum y otras políticas de resiliencia.

¿Cuánto cuesta una solicitud de API?

Cada cálculo mediante la API cuesta $0.002. Esta misma calculadora determinista también puede ejecutarse gratis en el navegador.

Todo lo de esta página está disponible por programación. Esta sección es para equipos que quieren integrarlo en sus sistemas; el resto puede usar la herramienta de arriba sin más.

POSThttps://api.kit.forhosting.com/dev/servers-needed

¿Prefiere automatizarlo? Un POST autenticado crea la tarea; el resultado llega por webhook o enlace firmado. La misma capacidad también se ejecuta aquí en la web, por email y desde Telegram — y pronto también desde nuestra app.

curl -X POST https://api.kit.forhosting.com/dev/servers-needed \
  -H "Authorization: Bearer $KIT_KEY" \
  -H "Content-Type: application/json" \
  -d '{"target_request_rate":10000,"per_server_capacity":1200,"headroom_percent":25}'
{
  "target_request_rate": 10000,
  "per_server_capacity": 1200,
  "headroom_percent": 25
}
{
  "task_id": "tsk_a1b2c3d4e5f6a1b2c3d4e5f6",
  "type": "dev.servers_needed",
  "status": "queued",
  "_links": {
    "result": "/tasks/tsk_…/result"
  }
}

La API es asíncrona: la llamada devuelve un task_id al instante y el resultado llega por webhook. El polling está limitado a 1 req/s por tarea.

Por solicitud$0.002

Precio publicado — sin tokens ni créditos inventados. Una tarea fallida no se cobra.

HTTPCódigoSignificado
401unauthorizedAPI key ausente o inválida.
402insufficient_balanceEl saldo no cubre el precio de la tarea.
404unknown_typeEl tipo de tarea no existe.
429rate_limitedDemasiadas peticiones. Use el webhook en vez de sondear.

Ver la documentación completa del KIT →