En la entrada de hoy voy a explicar un poco de teoría en lugar de prácticas como habitualmente hago, concretamente, voy a intentar explicar un poco el funcionamiento de cada MPM de apache.

Primeramente, hay que saber que cuando nos referimos al MPM de apache hablamos del módulo de multiprocesamiento de Apache o, en inglés,  MultiProcessing Manager (MPM). Es decir, el módulo MPM es el módulo de Apache que se encarga de gestionar, spawnear y controlar los procesos de Apache.

 

Existen unos cuantos módulos MPM de Apache, muchos de ellos experimentales como itk, winnt, netware, etc.. pero mayoritariamente se utilizan únicamente 3 módulos MPM, que son prefork, worker y event.

Prefork:

Prefork es el módulo que viene por defecto en Apache y el módulo con una mayor compatibilidad. Es un MPM basado en procesos, perfecto para sitios webs que no requieran que se generen múltiples hilos, y también es interesante desde el punto de vista de la seguridad pues aísla cada petición HTTP.

Su funcionamiento  consiste en realizar un «pre-fork» de los procesos necesarios al lanzar Apache. Pensemos en un tenedor donde cada punta del mismo es un proceso que cuelga del tenedor en sí, que sería Apache. Al lanzar Apache se genera un proceso maestro que es el encargado de lanzar todos los procesos hijos que responderán a las peticiones entrantes. No ofrece mal rendimiento de carga al cliente, pues se generan/spawnean todos los procesos necesarios al levantar el servidor web, pero es costoso a nivel de servidor, lo que a su vez se traduce en mala experiencia del cliente si la carga del servidor es elevada.

Su configuración es la siguiente:

#StartServers: Número de procesos de servidor que iniciar
#MinSpareServers: Número mínimo de procesos que mantener en «Spare/Espera»
#MaxSpareServers: Número máximo de procesos que mantener en «Spare/Espera»
#ServerLimit: El valor máximo para MaxClients durante la duración del Server
#MaxClients: El número máximo de procesos que el servidor puede generar
#MaxRequestsPerChild: El número máximo de peticiones que un proceso del servidor puede servir.

<IfModule prefork.c>
StartServers       8
MinSpareServers    5
MaxSpareServers   20
ServerLimit      256
MaxClients       256
MaxRequestsPerChild  4000
</IfModule>

 

Worker:

Worker es un MPM basado en hilos, no en procesos. Al utilizar hilos para servir las peticiones web, en lugar de procesos, permite al servidor web hacer frente a una mayor cantidad de peticiones con un consumo de recursos menor comparado a Prefork.  Su funcionamiento consiste en que un único proceso padre genera procesos hijos los cuales a su vez generan hilos que se encargan de gestionar las peticiones web. Su configuración es similar a la de Prefork:

#StartServers: Número de procesos de servidor que iniciar
#MaxClients: Número máximo de conexiones simultáneas de clientes
#MinSpareThreads: Número mínimo de hilos de Worker que se pueden quedar en spare
#MaxSpareThreads: Número máximo de hilos de Worker que se pueden quedar en spare
#ThreadsPerChild: El número de hilos de worker que se generan en cada proceso de servidor.
#MaxRequestsPerChild: El número máximo de peticiones que un proceso de servidor puede procesar.

<IfModule worker.c>
StartServers         4
MaxClients         300
MinSpareThreads     25
MaxSpareThreads     75
ThreadsPerChild     25
MaxRequestsPerChild  0
</IfModule>

 

Event:

Y llegamos al último módulo y en mi opinión el módulo que se debería utilizar actualmente, pues da un rendimiento muy elevado.

El funcionamiento de event es, en esencia, el mismo que en Worker, pero con una diferencia y es que Event dedica un hilo para cada petición http en lugar de un hilo para toda la conexión HTTP. Es decir, un cliente que realice 15 peticiones web generará 15 hilos para cada petición en lugar de uno único para la conexión HTTP.

Event soluciona el problema del KeepAlive en Apache, que provocaba un gasto de recursos elevados al mantener una conexión en spare por si el cliente volvía a enviar peticiones, al utilizar un hilo de gestión dedicado exclusivamente a tratar los sockets en escucha, los sockets en Keep Alive y los sockets que ya han realizado su trabajo (enviado información al cliente).

Traducido a otras palabras, utiliza un hilo propio para gestión de los sockets y multi-hilo para la gestión de las peticiones web.

Además, Event funciona genial con  PHP-FPM, que tiene un funcionamiento bastante similar, lo que provoca una gestión inteligente de los recursos del servidor, que se traduce en un rendimiento muy bueno.

La configuración de Event es la siguiente:

#MinSpareThreads: Número mínimo de hilos en Spare
#MaxSpareThreads: Número máximo de hilos en Spare
#ThreadsPerChild: Número de hilos por proceso hijo
#ThreadLimit 64: Número máximo de hilos a generar.
#MaxRequestsPerChild 20000: Número máximo de peticiones que un hilo hijo puede atender.

<IfModule event.c>
MinSpareThreads 64
MaxSpareThreads 128
ThreadsPerChild 64
ThreadLimit 64
MaxRequestsPerChild 20000
</IfModule>

Espero que os aclare algunas dudas sobre el funcionamiento de los MPM más usados de Apache.


0 comentarios

Deja una respuesta

Marcador de posición del avatar

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