Apache en Plesk: optimizar con medidas, no con recetas
Antes de «optimizar Apache», conviene averiguar qué está atendiendo Apache. En Plesk puede trabajar detrás de Nginx, ejecutar distintas configuraciones de PHP y compartir recursos con correo, bases de datos y copias de seguridad.
Medir el cuello de botella
Observa latencia, peticiones concurrentes, uso de memoria y errores bajo una carga representativa. Una respuesta lenta de PHP o una consulta a la base de datos puede parecer un problema del servidor web cuando no lo es.
Anota la configuración actual y cambia una variable cada vez. El objetivo es una mejora que puedas repetir, no una lista más larga de directivas.
Módulos y modelo de procesos
Mantén los módulos que necesitan los sitios alojados. Desactivar uno porque una receta lo considera «innecesario» puede romper autenticación, compresión o reglas de una aplicación.
El MPM determina parte del modelo de concurrencia. event puede ser adecuado en configuraciones compatibles, pero no es el predeterminado en todas las distribuciones ni debe cambiarse sin revisar PHP y los módulos cargados.
Particularidades de Plesk
Usa las opciones del panel y los archivos de inclusión previstos para personalizaciones. Los archivos generados pueden ser sobrescritos.
Los registros mediante tuberías (piped logs) permiten gestionar el registro a través de un proceso. No equivalen a desactivar los logs ni son una garantía automática de más rendimiento. Del mismo modo, cambiar el intervalo de reinicio de Apache exige entender cuándo Plesk aplica sus cambios.
Referencias: optimización de Apache en Plesk y MPM event.
Medir antes de ajustar procesos
Workers, keep-alive y timeouts dependen de RAM, tráfico y PHP-FPM. Obtén una línea base, valida con apachectl -t, cambia una variable y conserva el valor anterior. Una sintaxis válida no demuestra que la aplicación responda bien.
Prueba rutas dinámicas y caché como visitante. Compara con Nginx en Plesk. Fuente: directivas MPM de Apache.
0 comentarios
Sé concreto, añade contexto (versión, distro, stack) y si puedes pega logs en bloque de código. Menos drama, más señales.