Optimización de Apache

httpd Apache
Siguiendo con el último post sobre fine tuning de MySQL para mejorar el rendimiento, me lanzo con otro post recopilatorio con un resumen de algunas de las recomendaciones oficiales de Apache, completadas con otras fuentes listadas al final del post.

Hardware y SO

En la documentación oficial de Apache se comenta, que el factor más importante para el rendimiento de un servidor es la RAM, lo cual me recuerda a una frase que reproduzco casi literalmente, pero de la cual no consigo recordar la fuente:

«Aumentar la RAM es la manera más rápida, barata y eficaz de mejorar el rendimiento»

Además de la RAM, se deberá prestar atención a la i/o de los discos, CPU y finalmente a la velocidad de la tarjeta de red, que deberán ser suficientes (ésto se deberá determinar por experimentación).

Directivas

MaxClients: Ésta es una de las directivas más importanes, pues determina el número máximo de peticiones simultáneas que Apache puede atender. La idea es no permitir más conexiones de las que se pueden atender, para evitar usar swap, lo cual disminuye en mucho el rendimiento global. Las peticiones que no se puedan atender se pondrán en cola, según el valor de la directiva ListenBacklog. Se explica cómo se calcula éste número (de forma aproximada) en la documentación oficial, pero se entiende mejor de la fórmula de devside.net:

MaxClients ≈ (RAM – size_all_other_processes)/(size_apache_process)

  • RAM: se puede usar «free -m» para ver la ram total en MB, o cat /proc/meminfo, entre otras.
  • size_apache_process: Se podrá calcular el tamaño de un proceso httpd con «ps -ylC httpd –sort:rss», el cual mostrará todos los procesos httpd en ejecución, de menor a mayor tamaño, en bytes, para la columna RSS (Resident Set Size: «la memoria no-swap que ha usado, en KB»). Se podrá coger el tamaño mayor (dividido entre 1024 para tenerlo en MB) como «size_apache_process», o siendo menos severos, usar la siguiente fórmula, la cual calcula la media de los procesos actuales de Apache, ya en MB:

ps -ylC httpd –sort:rss | awk ‘{SUM += $8; I += 1} END {print SUM/I/1024}’

  • size_all_other_processes: Siguiendo la regla anterior, se podrá ver el uso de memoria por los procesos que no sean de Apache, con la fórmula descrita a continuación, la cual ya devolverá el resultado en MB (Aquí la fuente):

ps -N -ylC httpd –sort:rss | awk ‘{SUM += $8} END {print SUM/1024}’

Así por ejemplo:

  • free -m = 999MB (Mem total)
  • ps -ylC httpd –sort:rss | awk ‘{SUM += $8; I += 1} END {print SUM/I/1024}’ = 20.5458 (de 10880 a 34084)
  • ps -N -ylC httpd –sort:rss | awk ‘{SUM += $8} END {print SUM/1024}’ = 343.441
  • Max_Clients = (999 – 343.441) / 20.5458 = 31,9 => 31 (aproximado)

DirectoryIndex: Aquí se debe especificar un listado de páginas que resolverán como índices, indicando como primera opción la opción más probable. Por ejemplo, en un servidor PHP donde el index suela ser un archivo del estilo index.php especificaremos:

DirectoryIndex index.php index.html

De esta manera, se aceptarán archivos llamados index.php e index.html como archivos que se mostrarán cuando se hace una petición a un dominio sin indicar el fichero que se quiere ver (que es lo habitual).

AllowOverride: Para un mayor rendimiento, deberíamos indicar de forma global, y en todos los virtualhost, «AllowOverride None», para evitar que a cada petición, busque si existe o no un fichero .htaccess en los directorios de la petición (Ej. para un DocumentRoot /var/www, buscará un.htacess en /, otro en /var y otro en /var/www). Por contra, no podremos usar archivos .htaccess en aquellos virtualhost que hayamos configurado así.

FollowSymLinks y SymLinksIfOwnerMatch: Para evitar llamadas extra en cada petición, se deberá configurar para cada «Directory» de cada VirtualHost, lo siguiente:

‘Options +FollowSymLinks -SymLinksIfOwnerMatch’

HostnameLookups: Esta directiva ya viene en las versiones superiores a Apache 1.3, en Off por defecto, y previene así aumentar la latencia de las peticiones HTTP por culpa de la resolución DNS. Si no lo está ya, se recomienda ponerla a Off.

Módulos de Multi-Procesamiento (MPM)

Apache «viene con una serie de Módulos de MultiProcesamiento que son los responsables de conectar con los puertos de red de la máquina, acceptar las peticiones, y generar los procesos hijo que se encargan de servirlas» (Fuente). Básicamente:

  • Worker: usa múltiples procesos hijos, con múltiples threads cada uno. Cada thread gestiona una conexión a la vez. Generalmente, se recomienda en entornos de alto tráfico.
  • Prefork: usa múltiples procesos hijos, con un único thread cada uno. Cada proceso gestiona una conexión a la vez. Puede trabajar con módulos de terceros.

Aquí más información sobre estos MPM. Por cierto, se puede ver con qué MPM estamos trabajando, ejecutando la siguiente línea, lo cual nos devolverá, entre otros, prefork.c o worker.c:

/usr/sbin/apachectl -l

APC

Si se quiere mejorar el rendimiento de un servidor web, PHP, una muy buena opción es instalarle APC, una caché que optimiza el código PHP intermedio y mejora notablemente el rendimiento del servidor. Sin duda, una utilidad que debería estar instalada en prácticamente cualquier servidor Apache/PHP, ya que tiene una instalación muy sencilla (se encuentra en yum) y efectos notables en el rendimiento.

 

Fuentes:

http://httpd.apache.org/docs/2.0/misc/perf-tuning.html

http://www.devside.net/articles/apache-performance-tuning

http://beginlinux.com/blog/2010/07/apache-performance-tuning/

Flickr! Foto por US Mission Geneva

2 respuestas a «Optimización de Apache»

  1. Aprovecho para comentar que al subir MaxClients se pueden subir algunos otros parámetros para el módulo en el que se sube.

    Por ejemplo (copio y pego de la doc de Apache): ServerLimit «With the prefork MPM, use this directive only if you need to set MaxClients higher than 256 (default). Do not set the value of this directive any higher than what you might want to set MaxClients to.»

    Así pues, parece lógico poner el mismo valor tanto para MaxClients como para ServerLimit, en el caso de prefork.

Responder a Adri Cancelar la respuesta

Tu dirección de correo electrónico no será publicada.