Optimización servidor web Apache (I)

Aunque cada caso y sistema es un mundo y solo la observación, medida (lo que no se mide no se puede mejorar) y nuestra experiencia nos darán la solución adecuada, os voy a dejar una serie de consejos para empezar al menos con buen pie.

 

 

Mejoras en tiempo de compilación:

1)  No compilar lo que no se necesite, cuanto más ligero, mejor.

2) Lo que sepamos seguro que se necesita compilado de manera estática.

3) Lo que pensemos que podemos necesitar, podemos compilarlo como módulo.

4) Usar optimizaciones del compilador. Un ejemplo puede ser algo tal que así:

CC=”gcc” CXX=”gcc” CFLAGS=”-O3″ CXXFLAGS=”-O3 -fPIC -mtune=nocona -march=nocona
-pipe -fomit-frame-pointer -msse -fexceptions -fno-strict-aliasing -fPIC -Wall -fno-rtti -fno-strict-aliasing
-ffast-math -mfpmath=sse,387 -finline-functions -foptimize-sibling-calls
-floop-optimize -fprefetch-loop-arrays -fforce-addr -fexpensive-optimizations”

5) Compilar  (ya sea en módulo o estático) con opciones de cache (a disco o memoria) y compresión (deflate o gzip)


Mejoras en configuración:

1) Seleccionar el MPM adecuado:

  • prefork: es el método tradicional, en el se crean varios subprocesos y cada petición será atendida por uno de ellos. Es el que menos rendimiento da, pero también el que mejor funciona con módulos que no están preparados para trabajar con hebras como por ejemplo los aceleradores de PHP que no son Thread safe.Como norma general requiere más memoria y cpu para igual carga que otras opciones.
  • worker: un enfoque intermedio, en el que se crean varios subprocesos, que a su vez crearan varias hebras por subprocesos, que serán las que atenderán las peticiones.Solo se puede usar con módulos y extensiones que sean Thread Safe.

2) Configurar adecuadamente worker y prefork, atendiendo a los siguientes parámetros MaxClients, MinSpareServers, MaxSpareServers, StartServers y MaxRequestsPerChild. El valor de cada uno de estos parámetros dependerá de muchas cosas, pero os voy a dar un punto de comienzo sobre el que empezar a trabajar:

  • MaxClients: Se puede usar la reglaMaxClients=RAM/ Tamaño máximo de Proceso ChildEl tamaño máximo de un proceso child dependerá (tenéis que ver vuestro caso), pero orientativamente servir un fichero estático consumo entre 2 y 3MB y si usamos PHP entre 5 y 15 MB .
  • MinSpareServers: determina el nº mínimo  de servidores ociosos que tendremos esperando trabajo. Si tenemos un número bajo y entra carga de golpe, nuestro servidor tendrá problemas, ya que crear esos procesos consume tiempo y CPU.
  • MaxSpareServers: determina el nº máximo de procesos ociosos esperando carga. Si es un nº alto estamos desaprovechando memoria y capacidad de la máquina que podría dedicarse a otra cosa.

Como se puede ver MaxSpareServers y MinSpareServers están relacionados y una buena regla es fijarlos a tal número que el servidor Apache no requiera crear más de 4 procesos por segundo. En teoría se podrían llegar a 32 por segundo, pero esto no es recomendable y sobrepasado ese umbral obtendremos un error.

  • MaxRequestsPerChild: fijará el número máximo de peticiones “Per Child”, 0 para no poner limite. Desde mi experiencia en servidores con mucho tráfico se puede fijar a unos cuantos cientos (300), para evitar memory leaks si los procesos mueren.

3) KeepAlive y KeepAliveTimeout, para mantener abierta una conexión y que el cliente pueda reutilizarla. Dependerá de la aplicación pero entre 2 y 5 segundos puede ser un buen valor para servidores con mucha carga.

4) HostnameLookups, si no lo necesitamos este parámetro a Off y así evitamos esperar a la resolución de nombres, con la carga que esto genera.

5) No usar .htaccess , (AllowOverride None), sino en cada petición Apache chequeara ese fichero y eso es carga y tiempo.

6) Permitir symlinks, sino en cada petición Apache generará otra para comprobar si el fichero es un symlink.

7) Sino necesitamos las estadísticas (ExtendedStatus), se pueden desactivar.

8) Usar mod_gzip/mod_deflate para ahorrar ancho de banda.
Y con esto termino este primer artículo que ampliare en el siguiente con algunas consideraciones menos evidentes que pueden ayudarnos a ganar esa pizca de performance ;-).

Para más información www.apache.org

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios.