¿Cómo optimizar un servidor Apache?

---

Si tu web tarda en responder, devuelve errores 503 o se resiente cuando entra más tráfico, tiene sentido revisar Apache. Pero optimizar un servidor Apache no consiste en bajar valores a ciegas. Lo que de verdad funciona es detectar primero el cuello de botella y tocar solo lo que lo está frenando.

Apache sigue siendo un servidor web muy usado por su flexibilidad y su madurez. Además, es un proyecto mantenido por la Fundación de Software Apache. En Debian y Ubuntu, buena parte de la configuración suele vivir en /etc/apache2/. Antes de hacer cambios, crea una copia de seguridad y asegúrate de que sabes qué problema quieres resolver.

---

Cómo mejorar el rendimiento de un servidor Apache: pasos a seguir

TABLA DE CONTENIDOS

• Cómo saber si Apache es realmente el problema
  • No es lo mismo un servidor VPS que un hosting web
• Ajustes básicos de Apache que más se notan en el rendimiento
  • KeepAlive
  • KeepAliveTimeout y Timeout
  • MaxKeepAliveRequests
• Cómo influye el MPM de Apache en el rendimiento
• Compresión, caché y otros ajustes que ayudan a servir más rápido
  • Compresión
  • Caché del navegador
  • HTTP/2 y HTTPS
  • Módulos, logs y archivos estáticos
• Errores comunes al optimizar Apache
• Cuándo conviene revisar PHP, MySQL o la arquitectura del servidor
• Conclusión
• Preguntas frecuentes sobre cómo optimizar un servidor Apache (FAQ)

---

Cómo saber si Apache es realmente el problema

No toda web lenta tiene un problema en Apache. A veces el cuello de botella está en PHP, en MySQL, en el disco o incluso en una aplicación mal optimizada. ¿La clave? Comparar síntomas y medir antes de tocar la configuración.

Una comprobación muy útil es comparar una URL estática con una dinámica. Si un archivo CSS o una imagen responde rápido, pero la página principal tarda mucho, Apache no suele ser el único culpable. También conviene revisar /var/log/apache2/error.log, el uso de memoria, el estado del disco y el comportamiento del servidor justo en las horas con más tráfico.

No es lo mismo un servidor VPS que un hosting web

Aquí conviene hacer una distinción importante. En un servidor VPS tiene sentido hablar de KeepAlive, Timeout, MaxKeepAliveRequests, MPM o MaxRequestWorkers porque normalmente tienes acceso root o, como poco, control suficiente sobre Apache. El panel puede ser Plesk o cualquier otro, o incluso no haber panel. Lo importante no es el panel, sino el nivel real de acceso al servidor.

En un hosting web compartido, el margen es distinto. Si trabajas con un hosting web de Axarnet, tienes acceso a Plesk y a ciertos ajustes útiles del entorno, pero no al mismo nivel que en un VPS con acceso root. En ese caso, suele tener más sentido optimizar la versión de PHP, la caché, el CMS, las imágenes, la compresión o las reglas disponibles en .htaccess antes que intentar aplicar cambios globales de Apache que no están a tu alcance.

Ajustes básicos de Apache que más se notan en el rendimiento

Hay muchos parámetros en Apache, pero no todos pesan igual. Si buscas mejoras reales, lo normal es empezar por cuatro frentes: el MPM, el número de workers, los timeouts y la entrega de archivos estáticos. Lo demás suele venir después.

Los comandos y rutas que verás a continuación están pensados para Debian y Ubuntu con acceso root o con permisos sudo. Si estás en un entorno compartido, parte de estos cambios no estarán disponibles tal cual.

En Debian y Ubuntu no todo se toca en apache2.conf. También es habitual revisar sites-available, conf-available y la configuración de módulos. Si tienes control del servidor, antes de recargar merece la pena seguir siempre una rutina sencilla:

sudo cp /etc/apache2/apache2.conf /etc/apache2/apache2.conf.bak
sudo apachectl configtest
sudo systemctl reload apache2

Estos son los ajustes que suelen notarse antes:

• Elegir bien el MPM. Si el modelo de procesos e hilos no encaja con tu forma de servir PHP, gastarás más RAM de la necesaria.
• Ajustar MaxRequestWorkers. Si lo dejas demasiado bajo, se formará cola. Si lo subes demasiado, el servidor puede entrar en swap y empeorar todavía más.
• Revisar KeepAlive y los timeouts. Son claves para no dejar recursos ocupados más tiempo del necesario.
• Reducir módulos innecesarios. Cada módulo extra añade complejidad. Si no lo usas, mejor quitarlo.
• Servir estáticos con compresión y caché. Aquí suele haber una mejora visible sin necesidad de tocar demasiado la aplicación.

Un detalle importante: optimizar Apache no es solo hacerlo "más rápido". También es hacerlo más estable cuando suben las conexiones. Muchas veces, la mejor mejora no baja medio segundo la carga, pero sí evita caídas y picos de saturación.

Qué papel tienen KeepAlive, Timeout y MaxKeepAliveRequests

Estas directivas controlan cuánto tiempo mantiene Apache una conexión abierta y cuánto tarda en dar por perdida una operación. Parecen detalles pequeños, pero influyen mucho en el uso real de workers y en la sensación de rapidez. Si trabajas en un VPS o en un servidor con acceso root, suelen estar entre los primeros puntos a revisar. Si estás en un hosting compartido, es normal que no puedas modificarlas de forma global.

KeepAlive

KeepAlive permite reutilizar una misma conexión para varias peticiones. En la práctica, suele ser buena idea dejarlo activado porque evita abrir y cerrar conexiones todo el rato. Eso reduce sobrecarga, algo especialmente útil en sitios con muchos archivos pequeños.

El error común no es tener KeepAlive On, sino combinarlo con un tiempo de espera demasiado alto. Si dejas conexiones abiertas durante demasiado tiempo, acabas reteniendo recursos que podrían estar atendiendo a otros usuarios.

KeepAliveTimeout y Timeout

KeepAliveTimeout marca cuántos segundos espera Apache por la siguiente petición dentro de la misma conexión. En sitios con bastante tráfico, un valor corto suele funcionar mejor. Como punto de partida, 1 a 3 segundos suele ser razonable.

Timeout es otra cosa: define cuánto tiempo espera Apache antes de dar por fallida una operación de lectura o escritura. Si lo dejas muy alto, los procesos pueden quedar ocupados demasiado tiempo. Si lo bajas demasiado, puedes romper subidas de archivos, peticiones lentas o integraciones que necesitan más margen. En muchos entornos, 30 a 60 segundos es un rango más sensato que los valores antiguos demasiado altos.

MaxKeepAliveRequests

MaxKeepAliveRequests limita cuántas peticiones se aceptan dentro de una misma conexión persistente. Dejarlo demasiado bajo reduce el beneficio de reutilizar conexiones. Dejarlo ilimitado no suele aportar gran cosa en la mayoría de proyectos. Un rango prudente para empezar suele estar entre 100 y 500, según el tráfico y el tipo de web.

Si quieres una base práctica para probar, puedes empezar con algo así y medir después:

KeepAlive On
MaxKeepAliveRequests 100
KeepAliveTimeout 2
Timeout 30

No es una receta universal. Si tu web hace subidas pesadas, usa proxy inverso o depende de respuestas lentas del backend, necesitarás ajustar con más cuidado.

Cómo influye el MPM de Apache en el rendimiento

El MPM es el mecanismo que usa Apache para repartir trabajo entre procesos e hilos. Dicho de forma simple, decide cómo atiende conexiones. Y aquí se gana o se pierde mucha memoria. Es un ajuste que solo tiene sentido revisar cuando controlas Apache a nivel de servidor.

En Debian y Ubuntu puedes ver el MPM activo con sudo a2query -M. Los tres más habituales son estos:

• prefork. Usa procesos separados. Es robusto y compatible con configuraciones antiguas, pero consume más RAM. Suele aparecer en entornos heredados con mod_php.
• worker. Usa procesos con varios hilos. Consume menos memoria que prefork y soporta mejor cierta concurrencia, siempre que los módulos usados sean adecuados.
• event. Es parecido a worker, pero gestiona mejor conexiones en espera. En muchos servidores modernos con PHP-FPM suele ser la opción más eficiente.

Si tu servidor se queda sin memoria con poco tráfico, prefork suele ser un sospechoso claro. Si trabajas con PHP-FPM y sigues usando prefork por herencia, pasar a event puede notarse bastante. En cambio, si dependes de mod_php, no conviene cambiar de MPM sin revisar antes la compatibilidad.

Aquí el objetivo no es elegir "el más rápido" en abstracto. El objetivo es elegir el que mejor encaja con tu stack actual y con la cantidad real de memoria disponible.

Compresión, caché y otros ajustes que ayudan a servir más rápido

Cuando Apache ya está razonablemente bien ajustado, el siguiente paso suele ser servir el contenido de forma más ligera. Esto mejora tiempos de respuesta y reduce trabajo repetido.

Compresión

Activar compresión para HTML, CSS, JavaScript, JSON o SVG suele merecer la pena. Si puedes usar Brotli, mejor. Si no, Gzip sigue siendo una opción válida. Lo importante es no perder tiempo comprimiendo archivos que ya van comprimidos, como JPG, PNG, WebP, MP4 o ZIP.

Caché del navegador

Si una imagen, un CSS o un JavaScript cambia poco, lo lógico es indicarle al navegador que lo guarde durante un tiempo. Cabeceras como Cache-Control o Expires ayudan mucho en sitios con visitas repetidas y reducen peticiones innecesarias al servidor.

HTTP/2 y HTTPS

HTTP/2 mejora la entrega de recursos cuando el sitio usa muchas peticiones pequeñas. En la mayoría de navegadores, esto implica tener HTTPS bien resuelto. Por eso, además de la parte de velocidad, conviene tener bien configurados los certificados de seguridad SSL. Seguridad y rendimiento no van por caminos separados.

Módulos, logs y archivos estáticos

También ayuda desactivar módulos que no se usan, evitar niveles de log demasiado verbosos en producción y revisar si ciertos archivos estáticos muy pesados deberían servirse con una capa adicional de caché o CDN. No siempre hace falta dar ese salto, pero cuando el tráfico crece, se nota.

Errores comunes al optimizar Apache

Muchos problemas de rendimiento no vienen por tocar poco, sino por tocar mal. Estos son algunos fallos habituales:

• Cambiar valores sin medir antes. Si no sabes qué está fallando, es fácil arreglar una cosa y romper otra.
• Subir demasiado MaxRequestWorkers. Sobre el papel parece buena idea, pero si el servidor no tiene RAM suficiente, acabarás en swap.
• Bajar Timeout de forma agresiva. Puede provocar errores en peticiones legítimas, subidas de archivos o respuestas lentas del backend.
• Desactivar KeepAlive por sistema. En muchos sitios modernos eso empeora la eficiencia en lugar de mejorarla.
• Cambiar de MPM sin revisar cómo se sirve PHP. Si no entiendes esta parte, puedes encontrarte con incompatibilidades o inestabilidad.
• Intentar aplicar ajustes globales en un hosting compartido. Si no controlas Apache a nivel de servidor, la mejora real suele estar en otras capas.
• Pensar que Apache lo arregla todo. A veces el verdadero problema está más abajo: aplicación, base de datos, disco o arquitectura.

Otra mala práctica muy común es copiar una configuración "milagro" de internet. Lo que funciona bien en un servidor con 16 GB de RAM y PHP-FPM no tiene por qué servir en uno mucho más pequeño o con una aplicación muy distinta.

Cuándo conviene revisar PHP, MySQL o la arquitectura del servidor

Si después de optimizar Apache la mejora es pequeña, probablemente el límite está en otra parte. Esto pasa mucho más de lo que parece.

Conviene mirar PHP o la aplicación cuando las páginas dinámicas tardan mucho más que los estáticos, cuando el pool de PHP-FPM se satura o cuando una sola petición consume demasiada CPU. Conviene mirar MySQL cuando hay consultas lentas, bloqueos, tablas pesadas o picos de I/O en disco. Y conviene mirar la arquitectura general cuando el mismo servidor hace demasiadas cosas a la vez: web, base de datos, correo, copias, cron y más.

En proyectos que han crecido, llega un punto en el que ajustar Apache ya no basta. En ese escenario, tener una base más sólida de servidores de alojamiento web Linux o un entorno mejor dimensionado pesa más que seguir afinando parámetros uno a uno.

La idea importante es esta: Apache forma parte del rendimiento, pero no siempre es el centro del problema. Cuanto antes localices el cuello de botella real, antes dejarás de perder tiempo.

Conclusión

Optimizar Apache tiene sentido cuando el cuello de botella está realmente ahí y cuando tienes margen para tocar su configuración. En un VPS o en cualquier entorno con acceso root, revisar el MPM, los workers, KeepAlive o los timeouts puede mejorar bastante la estabilidad y los tiempos de respuesta.

Si trabajas con un hosting web de Axarnet, puedes apoyarte en Plesk y en otras opciones del entorno, pero no tendrás el mismo nivel de control que en un VPS. En ese caso, la mejora suele llegar antes por PHP, la caché, el CMS, las imágenes y las reglas disponibles que por intentar ajustar directivas globales de Apache.

Preguntas frecuentes sobre cómo optimizar un servidor Apache (FAQ)