Optimización de Apache

Optimizar los módulos

Apache utiliza módulos para extender sus características mucho más allá del paquete httpd del núcleo. La desventaja es que los módulos atan los recursos, y hay una gran probabilidad de que una configuración de Apache se esté ejecutando sin optimizar al menos en un par de módulos que no son necesarios.
Sólo se tarda unos pocos minutos en comprobar y desactivar cualquier módulo que no se esté utilizando. Para comprobar y ver qué módulos están activos, usa:
apachectl -M
Para las instalaciones de Debian / Ubuntu, utiliza estos comandos para permitir desactivar fácilmente los módulos:
Habilitar: module_name a2enmod
Desactivar: module_name a2dismod

 
Para distribuciones basadas en RPM como CentOS, vale la pena saber que los módulos se cargan directamente desde el archivo httpd.conf. Comienza por crear una copia de seguridad del archivo httpd.conf. A continuación, abre el archivo en tu editor preferido y simplemente comenta con (#) cualquiera de los módulos que no sean necesarios.
Para crear una copia de seguridad usa este comando:
cp -p /etc/httpd/conf/httpd.conf /etc/httpd/conf/httpd.conf.YYYY-MM-DD.bak
A continuación, realiza las modificaciones:
/etc/httpd/conf/httpd.conf vim
La documentación oficial de Apache 2.4 trae la lista de los módulos mínimos indispensables para el funcionamiento:
mod_mime
mod_dir
mod_log_config
Puedes técnicamente desactivar el módulo mod_log_config… pero te quedará sin ningún registro de eventos, algo nada recomendable. Esta configuración no se ejecutará en los sitios HTML estáticos más básicos. La configuración del módulo es totalmente dependiente de lo que necesita el servidor para hacer su trabajo.
Un mínimo de configuración del módulo de Apache para un sitio de WordPress, por ejemplo, podría ser algo como esto:
mod_alias
mod_authz_host
mod_autoindex
mod_deflate
mod_dir
mod_expires
mod_headers
mod_log_config
mod_mime
mod_negotiation
mod_rewrite
mod_setenvif
Esto trae algunas adiciones a los tres módulos originales y la configuración de WordPress en realidad puede requerir más módulos dependiendo de la configuración de tu sitio. Por ejemplo, si tienes una conexión SSL activa, también necesitas mod_ssl.
Si no estás familiarizado con los módulos individuales (o no te apetece investigar para saber lo que hace cada uno), todavía puedes experimentar con la configuración de tu sitio mediante la desactivación de módulos en secuencia y luego probar el sitio para determinar lo que funciona y lo que no.

Conoce tu MPM

Los módulos de procesamiento múltiple («MPM») definen la forma en que se manejan las solicitudes de Apache. Con el fin de obtener la experiencia más eficiente y fiable de tu servidor es importante utilizar la configuración que mejor se adapte a tu caso. Los tres módulos MPM más comunes son el «Prefork», el «Worker» y el recientemente introducido «Event».
Lista tus módulos MPM actuales:
Debian/Ubuntu-
apachectl -V | grep -i mpm
RPM –
httpd -V | grep -i mpm
Para cambiar tus MPM, activa el módulo adecuado. Por ejemplo, si estás usando Ubuntu y desear probar Prefork en lugar de Worker, usa:
a2dismod mpm_prefork
a2enmod mpm_worker
Y a continuación, comprueba que se ha producido el cambio:
apachectl -V | grep -i mpm

Prefork

Prefork (Pre-bifurcación) es el MPM más antiguo pero aún así es una configuración muy popular. Prefork maneja los trabajos HTTP mediante la creación de procesos secundarios para servir a esas solicitudes una por una. Como las solicitudes entran, Prefork intenta crear un proceso hijo con piezas que pueden esperar para nuevas solicitudes. Este sistema permite que el servidor permanezca libre para manejar las solicitudes adicionales mediante la creación de más procesos secundarios según sea necesario.
Prefork funciona muy bien hasta que se encuentra con muchas conexiones simultáneas, algo que incluso los usuarios individuales pueden generar muy rápido debido a la forma en que operan los navegadores modernos. En términos generales, la principal ventaja de Prefork es que es compatible con la mayoría de las configuraciones y es potencialmente muy eficiente, incluso más rápido que los MPM de encolado Worker y Event, siempre y cuando no sea necesario servir una gran cantidad de solicitudes simultáneas.
Utiliza prefork si necesitas una gran cantidad de módulos y no quieres preocuparte por la compatibilidad (o multi-hilo, es decir, cuando un código funciona correctamente durante la ejecución simultánea de múltiples hilos).
Muchos módulos populares no son compatibles con el proceso de cola utilizado por los módulos MPM Worker y Event, incluyendo mod_php, que todavía se utiliza comúnmente a pesar de la introducción de formas más eficientes para servir PHP. Así que revisa tus módulos para garantizar la compatibilidad del hilo mediante el uso de la documentación de Apache. También puedes considerar el uso de Prefork si necesitas un sitio que funcione de manera muy eficiente y no esperas gran cantidad de tráfico.

Worker / Event

Los módulos MPM Worker y Event utilizan múltiples hilos, de manera que pueden manejar bastantes más solicitudes simultáneas al permitir que los procesos secundarios descarguen procesos adicionales para las solicitudes. Esto difiere significativamente de Prefork, que sólo permite una solicitud para ser manejada en cada momento por cualquier proceso dado.
Mediante el uso de un MPM multi-hilos, puedes aumentar el rendimiento de tu servidor un poco, sobre todo en sitios de alto tráfico.
Los sitios de bajo tráfico son menos propensos a mostrar un cambio ya que es menos probable que se afecten los picos de solicitudes o se vean obligados a utilizar la memoria de intercambio de Prefork. Apache 2.4 introdujo Events, que es similar a Worker, salvo que se pueden utilizar procesos adicionales para manejar partes de las solicitudes antes de cerrar una conexión.
De acuerdo con la documentación de Apache, es aceptable utilizar Event donde el módulo Worker también es compatible. Event simplemente trae de nuevo las solicitudes de procesamiento de forma idéntica a Worker si se produce una incompatibilidad.
Usa MPM Worker o MPM Events si sabes que tu configuración es segura para los subprocesos. Si estás usando módulos no compatibles con el proceso, es posible que desees considerar otras alternativas.
Por ejemplo, en el caso de mod_php, que es de uso común, se podría utilizar en su lugar FastCGI y PHP-FPM. Este cambio no sólo te trae beneficios adicionales al permitirte usar un MPM multi-hilos, sino también el beneficio de un servicio más eficiente para la entrega de PHP.

Valores de los módulos

Una vez que seleccione su módulo de multiprocesamiento o MPM, deberá cambiar los valores dentro de la configuración. Estas configuraciones están ubicadas en /etc/apache2/apache2.conf si su sistema es Debian/Ubuntu, y el archivo /etc/httpd/conf/httpd.conf en CentOS/Fedora. El MPM luce así:
Extracto: /etc/apache2/apache2.conf (Debian/Ubuntu) o /etc/httpd/conf/httpd.conf (CentOS/Fedora)

<IfModule mpm_prefork_module>
    StartServers          4
    MinSpareServers       20
    MaxSpareServers      40
    MaxClients           200
    MaxRequestsPerChild  4500
</IfModule>

Para otros MPMs remplace la línea <IfModule mpm_prefork_module> por <IfModule mpm_worker_module> o <IfModule mpm_event_module> para worker o event respectivamente.
El próximo paso para reconfigurar su servidor Apache es alterar la configuración arriba. Para hacerlo, necesita estar al tanto de lo que hace cada valor, y cuál es la mejor manera de cambiarlo.
La mejor forma de hacer cambios en la configuración es hacer pequeños cambios, e ir supervisando los efectos.
Nota:
Después de hacer alteraciones al archivo de configuración Apache, reinicie el servicio usando el comando service apache restart en Debian/Ubuntu o /bin/systemctl reload httpd.service en CentOS/Fedora.

StartServers

El valor StartServers indica el número de procesos hijos creados en el inicio, y es controlado dinámicamente dependiendo de la carga. Realmente hay pocas razones para cambiar este número, a menos que su servidor se reinicie muy frecuentemente y reciba un gran número de solicitudes tras reiniciarse.

MinSpareServers

Establece el número mínimo de procesos hijos en estado de suspensión o idle. Si hay menos procesos que el número MinSpareServer, se crearán más procesos nuevos a una tasa igual o menor de un proceso por segundo en Apache 2.2. Con Apache 2.4, esta tasa aumenta exponencialmente comenzando con 1 y terminando hasta con 32 hijos generados por segundo. El beneficio de este valor es que cuando llega una solicitud, esta puede ser manejada por un hilo en suspensión; en caso de que no haya un hilo disponible, Apache tendría que generar un nuevo hilo, consumiendo recursos y extendiendo el tiempo que toma una solicitud en ser atendida. Tenga en cuenta también que tener demasiados procesos en suspensión también tendría efectos adversos en el servidor.

MaxSpareServers

Establece el número máximo de procesos hijos en suspensión. Si el número de procesos procesos en suspensión es mayor al valor de MaxSpareServers, entonces estos serán terminados. A menos que su sitio web sea extremadamente ocupado, este número no debería colocarse en un valor demasiado alto, debido a que incluso los procesos en suspensión consumen recursos.

MaxClients

La cantidad máxima de solicitudes que pueden ser servidas simultáneamente, con cualquier número por encima del límite que está en cola. Si este valor es muy bajo, las conexiones enviadas a la cola eventualmente expirarán; sin embargo, si el valor es demasiado alto, causa que la memoria comience a hacer demasiados intercambios (swapping). Si este valor es aumentado por encima de 256, el valor ServerLimit también debe ser aumentado en consecuencia.
Una manera de calcular el mejor valor para esto es dividir la cantidad de RAM que usa cada proceso de Apache entre la cantidad de RAM disponible, dejando un espacio para otros procesos. Use ApacheBuddy para determinar estos valores, o los comandos especificados a continuación:
Para determinar la RAM que cada proceso de Apache utiliza, remplace httpd por apache2 si utiliza sistemas Debian o Ubuntu:

ps -ylC httpd --sort:rss

Divida el número entre 2048 para megabytes.
Para obtener información sobre el uso de memoria:

free -m

Para recibir una vista más completa de los recursos que está usando Apache, utilice el comando top.

MaxRequestsPerChild

Este valor limita el número de solicitudes que un servidor hijo maneja durante su vida útil. Una vez que el limita ha sido alcanzado, el servidor hijo muerte. Si se establece en 0, los servidores hijos están configurados para nunca expirar. El valor sugerido para este parámetro es unos cuantos miles, para prevenir la fuga de memoria. Tenga en cuenta que establecer este parámetro en un valor muy bajo puede ralentizar el sistema, ya que crear nuevos procesos consume recursos.

ServerLimit

Si debe aumentar el valor MaxClients por encima de 256, entonces aumente ServerLimit a un valor coincidente. Para hacerlo, agregue la línea de ServerLimit a su código MPM y altere el valor:

ServerLimit          256

KeepAlive

La directiva KeepAlive, cuando se coloca en "on" permite recibir varias solicitudes que provienen de la misma conexión TCP. Cuando se usa una conexión KeepAlive, se cuenta como una sola solicitud contra las directivas MaxRequestsPerChild. Este valor es mantenido fuera de su MPM, pero puede vincularse estrechamente con su selección de MPM.

calcular el valor de maxclients en la configuoracion de apache

Para calcular el valor del parametro MaxClients en Apache, tenemos que conocer la siguiente formula:
MaxClients = Total de la RAM del Servidor en MB / Tamaño de un proceso Apache

Para calcular lo que ocupa en memoria un proceso de apache de tu servidor utilizamos el siguiente comando:
> ps -ylC httpd

procesos apache1

Y vemos que la columna SZ (Size) te dice el tamaño de cada petición apache. En este caso podemos ver qeu aproximadamente son 70M.
Vemos ahora mismo las peticiones Apache que tenemos actualmente:
> lsof -i | grep httpd | grep ESTABLISHED | wc -l
Podemos sacar una media calculando este valor en distintas horas del día, o coger el valor máximo para saber el uso de memoria maximo que podemos tener.
En este caso, voy a coger el valor máximo en este periodo de tiempo que son 19 peticiones.
Y podemos calcular:
Memoria RAM usada por Apache = 19 * 70M = 1330 M
Ahora ya podemos calcular el MaxClients para un servidor con 4G de memoria RAM
MaxClients = 4.000M / 70M = 57
Esta claro que este servidor sería un claro ejemplo para optimizar los procesos Apache, eliminando módulos que no se utilicen para optimizar el servidor web.
Para curarte en salud, se recomienda dejar un 20% de memoria para los procesos del sistema. Con lo que la formula final sería
MaxClients = Total de la RAM del Servidor en MB * 80% / Tamaño de un proceso Apache