Calculadora de capacidad del servidor web
Calcule el rendimiento máximo a partir de workers y tiempo de respuesta.
Quick Presets
Rendimiento por worker
20.0 req/sec
Rendimiento máximo
40.0 req/sec
Escenarios de escalado
| Número de workers | Rendimiento máximo | Status |
|---|---|---|
| 1 | 20.0 req/sec | — |
| 2 (current) | 40.0 req/sec | — |
| 4 | 80.0 req/sec | — |
| 8 | 160.0 req/sec | — |
¿Qué es una calculadora de capacidad web?
Una calculadora de capacidad web estima los recursos del servidor necesarios para manejar una cantidad dada de tráfico web. Te ayuda a determinar la CPU, RAM, ancho de banda y almacenamiento requeridos para alojar un sitio web o aplicación basándose en usuarios concurrentes esperados, tamaño de página y tasa de peticiones. Esto evita tanto el sobreaprovisionamiento (desperdiciar dinero) como el subaprovisionamiento (mal rendimiento).
La planificación de capacidad implica estimar el tráfico pico, el tiempo medio de respuesta y el consumo de recursos por petición. Un blog estático necesita recursos muy distintos a una aplicación web dinámica con consultas a base de datos. Esta herramienta calcula requisitos para arquitecturas web comunes incluidos sitios estáticos, plataformas CMS y servidores de aplicaciones.
Cómo usar esta herramienta
Introduce tu tráfico esperado (visitantes mensuales o usuarios concurrentes), tamaño medio de página y tipo de aplicación. La herramienta calcula las especificaciones recomendadas del servidor incluidos núcleos de CPU, RAM, ancho de banda y almacenamiento. También estima los costes de hosting para los principales proveedores cloud.
Métricas clave de capacidad
- Usuarios concurrentes — el número de usuarios usando activamente tu sitio al mismo tiempo. Típicamente 1-5 % de los visitantes diarios.
- Peticiones por segundo (RPS) — cada carga de página genera múltiples peticiones (HTML, CSS, JS, imágenes). Una página con 30 activos = 30 peticiones.
- Ancho de banda — datos totales transferidos. Calculado como tamaño de página * vistas. Una página de 2MB con 100.000 vistas mensuales = 200GB/mes.
- Tiempo de respuesta — el tiempo para generar y entregar una respuesta. Menos de 200ms es rápido, menos de 1 segundo es aceptable, más de 3 segundos pierde visitantes.
Estrategias de escalado
El escalado vertical significa actualizar a un servidor más grande (más CPU, RAM). El escalado horizontal significa añadir más servidores tras un balanceador de carga. Las CDN (Content Delivery Networks) descargan los activos estáticos a servidores edge en todo el mundo, reduciendo drásticamente la carga del servidor de origen. La caché (Redis, Varnish) sirve peticiones repetidas sin tocar la base de datos. Para la mayoría de los sitios con menos de 100.000 visitantes mensuales, un único servidor bien configurado con CDN es suficiente.
Ejemplo práctico
Un servidor atiende solicitudes que tardan 50 ms de media cada una. Por la ley de Little, un trabajador completa 1 ÷ 0,05 = 20 solicitudes por segundo. Ocho trabajadores dan 160 por segundo a plena utilización. Para mantenerte por debajo del 70% de utilización con margen, planifica unas 112 solicitudes por segundo antes de añadir capacidad.
Errores comunes
Un error común es planificar para el 100% de utilización; las colas crecen de forma explosiva al acercarse a la saturación, así que la latencia se dispara mucho antes del límite teórico. Otro es usar el tiempo de respuesta medio ignorando la cola lenta: unas pocas solicitudes muy lentas ocupan trabajadores y recortan el rendimiento real. Probar carga con tráfico irreal y amigable con la caché también sobrestima la capacidad.
Preguntas frecuentes
¿Cuánta RAM necesita un servidor web?
Para un sitio estático o CMS pequeño: 1-2 GB. Para un sitio mediano WordPress/aplicación (menos de 50K visitantes mensuales): 2-4 GB. Para aplicaciones de alto tráfico con bases de datos: 8-16+ GB. La base de datos suele consumir más RAM que el propio servidor web: PostgreSQL y MySQL se benefician enormemente de tener el conjunto de datos de trabajo en caché de memoria.
¿Cómo estimo el tráfico pico?
El tráfico pico suele ocurrir durante horas específicas y puede ser 3-10x la media. Para un sitio empresarial, el pico es durante horas de trabajo en tu zona horaria objetivo. Para sitios de consumo, tardes y fines de semana. Las campañas de marketing, menciones en redes sociales y cobertura mediática pueden causar picos repentinos de 10-100x el tráfico normal. Diseña para 3x la media como base, y usa autoescalado o CDN para manejar picos inesperados.
¿Por qué no debería planificar para el 100% de utilización del servidor?
La teoría de colas muestra que el tiempo de espera sube bruscamente al acercarse la utilización al 100%; al 90%, una pequeña ráfaga de tráfico puede causar grandes picos de latencia. Dejar margen —a menudo apuntando al 60 a 70%— absorbe ráfagas, conmutaciones por error y crecimiento del tráfico, manteniendo estables los tiempos de respuesta en vez de colapsar bajo carga.