¿Qué hosting de servidores dedicados necesito para un sitio web de alto tráfico?

¿Cómo dimensiono un servidor para una web con mucho tráfico?

Parte de las peticiones por segundo en hora punta y de cuánto tiempo ocupa cada petición a un worker, no de los visitantes al mes. Multiplica ambos y obtendrás el número de workers ocupados en cada instante. Con 300 peticiones por segundo y 0,1 segundos cada una, hay 30 workers ocupados de media. Duplica esa cifra para los picos.

Los visitantes mensuales no dimensionan un servidor; el minuto más cargado sí.

• CPU. Una petición que calcula usa un núcleo mientras se ejecuta. Los workers limitados por CPU necesitan aproximadamente un núcleo cada uno. Los workers que esperan a una base de datos o a una API pueden superar en número a los núcleos.
• Memoria. Cada worker tiene su propia memoria. Multiplica la cifra por worker por el número de workers y luego suma la caché de la base de datos y el sistema operativo.
• Almacenamiento. Los sitios con mucho tráfico suelen estar limitados por su base de datos. El NVMe local mantiene las consultas y los logs fuera de discos lentos.

Lumenfer no publica benchmarks, así que mide tu propia aplicación. Haz una prueba de carga sobre una copia con una herramienta como k6 o wrk y lee la memoria máxima por worker en top.

¿Cuántos workers deben ejecutar PHP-FPM, Node.js y nginx?

Fija el pm.max_children de PHP-FPM según la memoria, ejecuta un proceso de Node.js por núcleo y deja que nginx arranque un worker por núcleo.

• PHP-FPM. El manual de PHP dice que pm.max_children limita cuántas peticiones se atienden a la vez. static mantiene ese número de hijos en ejecución; dynamic y ondemand los arrancan según se necesiten. pm.max_requests reinicia los hijos tras un número determinado, una solución para librerías con fugas.
• Node.js. Un proceso de Node.js ejecuta JavaScript en un solo hilo. El módulo cluster ejecuta varios procesos que comparten un puerto. Su ejemplo de la documentación crea un worker por availableParallelism().
• nginx. El manual de nginx considera un buen punto de partida un proceso worker por núcleo de CPU, y auto detecta el número. worker_connections vale 512 por defecto y también cuenta las conexiones upstream. El límite de archivos abiertos lo condiciona, así que sube worker_rlimit_nofile a la vez.

# /etc/nginx/nginx.conf
worker_processes auto;        # one per CPU core
worker_rlimit_nofile 65535;   # open files per worker
events {
    worker_connections 8192;  # clients and upstreams together
}

# PHP-FPM pool, e.g. /etc/php/<version>/fpm/pool.d/www.conf
# pm = static
# pm.max_children = 64        ; free RAM for PHP / peak memory per child
# pm.max_requests = 1000      ; respawn children to contain leaks

¿Cuánto ancho de banda usa una web con mucho tráfico?

Menos de lo que temes cuando un CDN sirve los archivos estáticos, más de lo que esperas sin él. El Web Almanac 2025 de HTTP Archive sitúa la página de inicio media en 2,86 MB en escritorio y 2,56 MB en móvil. Las cifras proceden de su rastreo de julio de 2025. Las imágenes y el JavaScript son la mayor parte.

La aritmética para un origen sin CDN:

• 1 TB de tráfico soporta unas 390.000 cargas de página de inicio móvil sin caché a 2,56 MB.
• Un puerto de 1 Gbit/s llega como máximo a 125 MB por segundo: aproximadamente 49 de esas páginas por segundo.
• Treinta días a pleno rendimiento suman aproximadamente 324 TB.

Con el peso de página medio, un solo origen de 1 Gbit/s llega como máximo a unas 49 cargas de página sin caché por segundo. Un CDN lo cambia: el origen entonces envía sobre todo HTML y respuestas de API. Los planes Lumenfer van de 30 TB al mes a 1 Gbit/s a 150 TB al mes a 1 Gbit/s. Pasarse nunca genera un cargo automático.

¿Necesito un CDN delante de un servidor dedicado?

Sí, para cualquier sitio que espere tráfico real: descarga los bytes estáticos, absorbe los picos y se interpone entre los atacantes y tu origen. La protección DDoS se limita a lo que aplique por defecto la red del datacenter; no se promete nada más. Una inundación enviada a la única dirección IPv4 del servidor llega directamente a tu máquina.

Publica solo las direcciones del CDN en DNS y deja que el origen acepte tráfico web únicamente del CDN. No se guardan logs: ni logs de conexión, ni logs de tráfico, ni direcciones IP de visitantes o clientes, ni en el sitio, ni en el panel, ni en los servidores. Un CDN que añadas guarda sus propios logs bajo su propia política, así que léela antes de elegir uno.

¿Qué CPU conviene a una web con mucho tráfico: reloj alto o muchos núcleos?

Velocidad alta por núcleo para el tiempo de respuesta, más núcleos para peticiones en paralelo. Una sola petición de PHP o Node.js se ejecuta sobre todo en un núcleo, así que la velocidad de ese núcleo fija su latencia. El número de núcleos fija cuántas peticiones se ejecutan al mismo tiempo.

Los planes Ryzen combinan menos núcleos con velocidades de reloj de clase escritorio. Los planes EPYC añaden núcleos y memoria ECC. Nuestra guía sobre la mejor CPU para un servidor alquilado los compara, y el servidor más rápido que puedes alquilar explica qué criterios deciden la velocidad.

¿Debe la base de datos ejecutarse en el mismo servidor que la web?

En una sola máquina, sí, hasta que la base de datos y los workers empiecen a competir por la RAM. El hardware compartido mantiene las consultas locales y cuesta un solo plan. Cuando la caché de la base de datos se queda sin espacio, traslada la base de datos a su propio servidor con memoria ECC y conecta ambos por TLS.

Nuestra página sobre el mejor hosting de servidores para PostgreSQL cubre memoria, almacenamiento y copias de seguridad para esa segunda máquina.

¿Cuándo no basta un servidor para una web con mucho tráfico?

Cuando una hora de caída cuesta más que un segundo servidor. Una máquina es un único punto de fallo. No hay consola IPMI ni KVM-over-IP para los clientes: solicitas reinicios y reinstalaciones en el panel y el equipo los realiza. Las copias de seguridad no están incluidas: guarda copias de tus datos en otro sitio.

Para disponibilidad, ejecuta un segundo servidor en otra ciudad con replicación de base de datos y conmuta por DNS o por tu CDN. Ámsterdam (Países Bajos), Reikiavik (Islandia), Zúrich (Suiza) y Bucarest (Rumanía): los cinco planes en las cuatro ciudades, un mismo precio en todas. Un servidor en espera en Zúrich o Reikiavik cuesta exactamente lo mismo que en Ámsterdam.

En la comprobación de Lumenfer de 30 October 2026, 27 de 34 vendedores de servidores dedicados fijaban el precio de su servidor de entrada con un procesador anterior a 2018. Todos los planes Lumenfer ejecutan una CPU de 2022 o posterior, DDR5 y NVMe. Compara el coste total frente al cloud hosting en ¿es el bare metal más barato que la nube, y consulta todos los planes en la página de precios de Lumenfer.