Diferencias entre los módulos de procesamiento de Apache: Prefork, Worker y Event

Apache MPM (Multi Procesing Module) maneja y procesa las solicitudes entrantes, Prefork, Worker y Event son los distintos módulos de procesamiento que podemos elegir a la hora de compilar nuestro Apache, es decir que son los diferentes tipos de procesamiento.
En este artículo detallaré las características de cada uno de los posibles MPM (Prefork, Worker y Event), esto con el fin de que podamos adecuar la versión según las necesidades de nuestro servidor.

1) MPM Prefork
Es el módulo por default que trae Apache al momento de la instalación, tiene la particularidad de que crea diferentes procesos independientes o hijos para procesar las peticiones que ingresan a nuestro servidor. Se denomina forking, por eso su nombre.
Un solo proceso de control crea múltiples subprocesos hijo, como si fuera en rama o tenedor. Se encarga de que siempre haya varios procesos abiertos libres que puedan usarse al recibir varias peticiones.

Esta es la configuración default de MPM Prefork

StartServers 10
MinSpareServers 5
MaxSpareServers 25
ServerLimit 256
MaxClients 256
MaxRequestsPerChild 4200

Dónde:
StartServers: Es el número de procesos hijo que se iniciarán.
MinSpareServers: Es el número mínimo de procesos que el servidor siempre tendrá disponibles o libres.
MaxSpareServers: Es el número máximo de procesos que el servidor siempre tendrá disponibles o libres.
MaxClients: Es el número máximo de procesos que atenderá el servidor.
MaxRequestsPerChild: Es el número máximo de procesos hijo que puede tener cada uno de los StartServers.

Es el módulo más compatible y estable, aunque tiene como contra que consume un alto valor de RAM y CPU ya que al tener tantos procesos hijo y en «reserva» conlleva un gasto necesarios de recursos.

2) MPM Worker
Utiliza subprocesos hijo al igual que el MPM Prefork y a su vez estos procesos hijo crean hilos de ejecución, también llamados threads que se encargan de procesar peticiones, organizándose y delegando peticiones a otros procesos que ya están ejecutándose. Esto le permite servir un gran número de peticiones a cada proceso hijo.
Un solo proceso de control crea múltiples procesos hijo, a su vez cada proceso hijo crea threads o hilos de procesamiento controlados por la directiva ThreadsPerChild. Cada vez que ingresa una petición es asignada a un thread que la procesa y ejecuta.

En lugar de crear múltiples procesos hijo como lo hace prefork, worker crea y deja en espera múltiples hilos bajo cada hijo, de esa manera se asegura tener la capacidad de atender múltiples peticiones.

Esta es la configuración default de MPM Worker:

StartServers 5
MaxClients 350
MinSpareThreads 25
MaxSpareThreads 75
ThreadsPerChild 25
MaxRequestsPerChild 0

Donde:
StartServers: Es el número de procesos hijo que se iniciarán.
MaxClients: Es el número máximo de procesos que atenderá el servidor.
MinSpareThreads: Es el número mínimo de subprocesos que el servidor siempre tendrá disponibles o libres.
MaxSpareThreads: Es el número máximo de subprocesos que el servidor siempre tendrá disponibles o libres.
ThreadsPerChild: Es el número de threads por hijo que se ejecutan simultaneamente.
MaxRequestsPerChild: Es el número máximo de procesos hijo que puede tener cada uno de los StartServers.

Mejora considerablemente el uso de CPU y RAM, dado que es menor la cantidad de procesos hijo que se emplean, dando de esta manera una mejor performance al procesamiento de peticiones. El problema que tiene es que si un subproceso hijo queda inutilizado por algún problema se cancelan multiples hilos de procesamiento, haciendo que worker sea un poco inestable o con ineficiencia a la hora de resolver un problema.

3) MPM Event
Es una mejora de mpm worker, optimizado para trabajar con un número de peticiones elevadas. Lo que hace es servir más peticiones simultáneas con la ayuda de Keep Alive y permite que un usuario mantenga el hilo en ejecución para así enviar múltiples peticiones sin necesidad de abrir nuevas conexiones tcp.
En sí el funcionamiento es igual al de MPM Worker con esta mejora, pero los pro y los contras siguen siento también igual.

Esta es la configuración default de MPM Event:

MinSpareThreads 75
MaxSpareThreads 150
ThreadsPerChild 75
MaxRequestsPerChild 21000

Conclusión ¿Como elegimos nuestro MPM?
Recursos: Si tenemos recursos de sobra en el servidor, prefork es nuestra elección que nos serviría perfectamente. Ahora si los recursos del servidor son escasos deberíamos tirarnos por Worker o Event que hacen un mejor aprovechamiento de la RAM y CPU.
Contenido alojado en el servidor: Si tenemos contenido estático mayormente, lo mejor sería utilizar Worker o Event. Por otro lado si tenemos contenido dinámico deberemos evaluar otros factores a la hora de elegir el MPM aunque siempre se tenga a Prefork como preferido en este sentido.
Tráfico o visitas: Si el servidor tendrá un alto tráfico o numerosas visitas, no deberíamos usar Prefork debido a los recursos que consume.