Guía de optimización de CPU para sitios con alto tráfico

En los últimos dos años los servidores que atienden más de 80 000 visitas concurrentes han mostrado picos de uso de CPU superiores al 92 % durante eventos de venta flash. Esa cifra obliga a replantear cómo se distribuyen los procesos dentro del hosting y qué ajustes reales reducen la carga sin sacrificar estabilidad.

Entendiendo el impacto de la CPU en hosting de alto tráfico

La CPU actúa como el cuello de botella principal cuando el número de peticiones HTTP supera la capacidad de hilos disponibles del servidor. En entornos de hosting compartido o VPS con tráfico sostenido, cada milisegundo extra de procesamiento se traduce en colas que afectan la latencia percibida por el usuario final. — Más información: Kernel.org

Los kernels modernos como Linux 5.15 y superiores incorporan mejoras en el planificador CFS que permiten priorizar tareas de red frente a procesos secundarios. Aun así, la mayoría de instalaciones por defecto no activan estas afinidades, lo que deja margen de mejora medible.

Por qué la arquitectura del procesador importa

Los núcleos con alta frecuencia base pero pocos hilos por núcleo se comportan peor bajo cargas de tipo “muchas conexiones cortas” típicas de tiendas online. En cambio, procesadores con mayor cantidad de núcleos físicos permiten distribuir workers de Nginx o Apache sin que el sistema entre en thrashing.

• Los servidores con CPUs AMD EPYC de 64 núcleos han demostrado mantener el uso por debajo del 65 % en picos de 120 000 peticiones por minuto cuando se configura correctamente el balanceo de interrupciones.
• En plataformas Intel Xeon de generación anterior, el mismo volumen de tráfico suele requerir activar IRQ affinity manual para evitar que todas las interrupciones de red caigan sobre los mismos dos núcleos.

Arquitectura de servidores y gestión de hilos

La forma en que el servidor web crea y destruye procesos o hilos determina en gran medida el consumo de CPU. Nginx con worker_processes ajustado al número de núcleos físicos suele rendir mejor que Apache con prefork en escenarios de alto tráfico, aunque la diferencia se reduce cuando se habilita event MPM con suficientes hilos.

El uso de contenedores añade otra capa: cada contenedor Docker comparte el kernel pero mantiene su propio espacio de nombres de procesos. Esto permite aislar aplicaciones pesadas sin que una sola petición mal optimizada consuma todo el tiempo de CPU del host.

Configuración recomendada de workers

1. Establecer worker_processes al número exacto de núcleos físicos disponibles, nunca al doble (hyper-threading no siempre ayuda en cargas de red).
2. Definir worker_connections en 4096 o superior cuando la memoria RAM lo permita, vigilando que el sistema no entre en swap.
3. Activar multi_accept on para que cada worker acepte múltiples conexiones en una sola llamada al sistema.
4. Desactivar sendfile si se sirve contenido dinámico mayoritariamente, ya que en ese caso el beneficio de copia cero desaparece.

Optimizaciones a nivel de software y configuración

Más allá del servidor web, el lenguaje y el framework elegido influyen directamente en el tiempo de CPU por petición. Aplicaciones escritas en Go o Rust suelen requerir entre un 30 % y un 45 % menos de ciclos que equivalentes en PHP 8.2 con frameworks pesados, siempre que no se abuse de reflection o serialización innecesaria.

El uso de opcache en PHP o JIT en Node.js reduce la carga de interpretación repetitiva. Sin embargo, mantener el tamaño del opcache demasiado grande puede generar presión sobre la caché de instrucciones del procesador y producir caídas de rendimiento sutiles pero medibles.

Lista de ajustes concretos que suelen dar resultado

• Reducir el número de módulos Apache cargados a solo los estrictamente necesarios; cada módulo adicional añade entre 0,8 % y 2,3 % de uso de CPU en pruebas con 10 000 conexiones simultáneas.
• Configurar keepalive_timeout en 15 segundos como máximo para evitar que sockets inactivos retengan workers demasiado tiempo.
• Habilitar gzip en el servidor web pero limitar el nivel a 4 o 5; niveles superiores consumen CPU sin aportar mejora perceptible en la mayoría de conexiones modernas.
• Utilizar systemd para limitar la prioridad de procesos secundarios (nice value +10) de modo que las peticiones HTTP siempre tengan preferencia.

Monitoreo y ajuste continuo del rendimiento

Las herramientas de observabilidad permiten detectar cuellos de botella antes de que el sitio deje de responder. Prometheus con node_exporter y cAdvisor ofrece métricas por núcleo que revelan si una aplicación está monopolizando un solo hilo mientras el resto permanece ocioso.

El análisis de flamegraphs generados con perf o py-spy durante picos reales suele mostrar que entre el 35 % y el 50 % del tiempo de CPU se pierde en serialización JSON o en consultas repetidas a base de datos sin caché. Corregir estos puntos suele ser más efectivo que añadir más núcleos.

Métricas clave que conviene seguir

• Porcentaje de CPU por núcleo en intervalos de 5 segundos durante al menos 48 horas para detectar patrones diarios.
• Latencia de respuesta del percentil 95 y 99; un aumento sostenido por encima de 800 ms suele indicar saturación de workers.
• Número de cambios de contexto por segundo; valores superiores a 80 000 en un servidor de 16 núcleos suelen correlacionarse con inestabilidad.

Guía de optimización de CPU para sitios con alto tráfico en la práctica

Aplicar la guía de optimización de CPU para sitios con alto tráfico requiere combinar varios cambios en orden y medir después de cada uno. Saltarse esta secuencia suele generar regresiones difíciles de diagnosticar.

El primer paso consiste en realizar una línea base con herramientas como wrk o Apache Bench durante 10 minutos a la carga esperada. Posteriormente se ajustan los parámetros del servidor web y se repite la prueba. Solo cuando la ganancia se estabiliza se pasa a optimizar el código de la aplicación.

Orden recomendado de intervención

1. Actualizar el kernel y habilitar las optimizaciones de red disponibles en sysctl (tcp_fastopen, tcp_tw_reuse).
2. Reconfigurar el servidor web según el número real de núcleos y memoria disponible.
3. Introducir caché de objetos a nivel de aplicación (Redis o Memcached) para reducir consultas repetidas a base de datos.
4. Revisar consultas SQL con EXPLAIN y añadir índices o reescribir las que superen 50 ms de tiempo de ejecución promedio.
5. Implementar compresión Brotli solo para activos estáticos y dejar gzip para respuestas dinámicas.

Si quieres conocer otros artículos parecidos a Guía de optimización de CPU para sitios con alto tráfico puedes visitar la categoría Hosting.