Diferencias entre apache prefork, event y worker

En Desarrollo, Software, Webmasters por

Cuando nos disponemos a instalar Apache en su versión 2 por primera vez, resulta que en los tutoriales varía el tipo de Apache que emplean. En este artículo hablaremos sobre los diferentes módulos multiprocesamiento de Apache y las diferencias entre Apache prefork, event y worker (que son los diferentes tipos de módulos multiprocesamiento).

Diferencias entre apache prefork, event y worker

Tengo que dejar claro que en este artículo no vamos a mostrar como instalar o configurar cada uno de ellos, pero si os mostraremos las ventajas e inconvenientes entre usar un módulo multiprocesamiento de Apache u otro. También aclarar que todo lo que decimos en el artículo y cuando hablamos de Apache, es referente a la versión 2 de Apache y superiores.

Diferentes módulos multiprocesamiento de Apache.

En el momento de escribir el artículo disponemos de tres módulos multiprocesamiento de Apache considerados como estables y uno en versión experimental, que son los siguientes:

  • Multiprocesamiento tipo Prefork (mpm-prefork).
  • Multiprocesamiento tipo Worker (mpm-worker).
  • Multiprocesamiento tipo Event (mpm-event).
  • Multiprocesamiento tipo ITK (mpm-itk todavía en fase experimental).

Cuando hablamos de módulos multiprocesamiento en Apache nos referimos a las siglas MPM. Estos módulos son los que se encargan de las funciones internas más elementales del servidor Apache, como pueden ser procesar las peticiones HTTP, administrar procesos o hilos de Apache y un largo etc. Lo que si debemos tener claro es que podemos tener varios módulos MPM instalados pero solamente uno cargado y funcionando y en este artículo trataremos de ayudaros a elegir el módulo MPM de Apache que más os conviene.

Como nota, los nombres que usa la distribución Linux para los diferentes paquetes de los MPM son: apache2-mpm-prefork, apache2-mpm-worker, apache2-mpm-event y apache2-mpm-itk.

Multiprocesamiento tipo Prefork (mpm-prefork).

Es el módulo MPM instalado y usado por defecto en las instalaciones. Este módulo crea diferentes procesos independientes para manejar las diferentes peticiones. Esta técnica de crear varios procesos se la denomina forking, de ahí el nombre mpm-prefork. Al iniciar Apache Prefork se crean varios procesos hijo (el número de procesos que se crea dependerá de nuestra configuración).

Es la instalación por defecto porque es la que ofrece una mayor compatibilidad con los diferentes módulos. Existen módulos de Apache que no son seguros para usar con threads (no son thread-safe) por eso hay que recurrir a una versión de Apache que no use threads como es el Apache MPM Prefork (que usa procesos en lugar de threads). Un claro ejemplo de módulo muy usado que no es thread-safe es mod_php.

MPM Prefork es el módulo más estable pero también es el que más recursos consume (en cuanto a RAM y CPU) ya que mantener los diferentes procesos de Apache es “caro” en cuanto a recursos.

Multiprocesamiento tipo Worker (mpm-worker).

Es un módulo MPM que pretende mejorar el rendimiento frente a MPM Prefork y de hecho lo consigue. Este módulo usa procesos y al mismo tiempo hace uso de threads (también llamados hilos), es decir, combina las técnicas de forking y threading. Al iniciar Apache Worker se crean varios procesos hijo y a su vez cada proceso hijo emplea varios threads. Con esto se consigue que cada proceso hijo pueda manejar varias peticiones simultaneas gracias a los threads.

Entendiendo lo anterior, deducimos que empleando este método que combina procesos y threads requiere de un menor número de procesos hijo y cómo consecuencia emplea menos recursos de CPU y RAM (dónde más se nota el impacto es en el uso de CPU, que baja de forma drástica respecto a Prefork).

Pero no es oro todo lo que brilla, ya que MPM Worker al usar threads sólo soporta módulos de Apache que sean thread-safe, por lo que el famoso mod_php no puede ser usado con Apache MPM Worker. Otro inconveniente de MPM Worker es que si por algún motivo un proceso hijo tiene que ser terminado por circunstancias anómalas, se pierden todas las conexiones que manejan los threads de ese proceso hijo cancelado, es decir, ante fallos MPM Worker se comporta peor.

Volviendo al tema de mod_php y su incompatibilidad con MPM Worker, obviamente existe una alternativa a mod_php compatible con Worker que se llama php-fpm, la cual también ofrece sus ventajas e inconvenientes frente a mod_php. Resumiendo mucho una comparativa entre mod_php y php-fpm podríamos decir:

  • Ventajas de mod_php: nos ofrece velocidad y facilidad de configuración.
  • Ventajas de php-fpm: nos ofrece un mejor uso de recursos (RAM y CPU) y mayor eficiencia.
  • Inconvenientes de mod_php: consume más recursos.
  • Inconvenientes de php-fpm: configuración más complicada.

Multiprocesamiento tipo Event (mpm-event).

MPM Event hasta hace poco era considerado como experimental pero hoy en día ya es una opción estable. Es una mejora de MPM Worker y soluciona un problema de optimización que mostraba MPM Worker con la opción Keep Alive de Apache. No quiero entrar en una explicación detallada sobre el problema de optimización y confundiros con datos técnicos, por lo que seré breve y diré que MPM Event mejora el rendimiento de Apache durante las peticiones con Keep Alive, que son muy comunes.

Como MPM Event está basado en MPM Worker, tiene las mismas ventajas e inconvenientes que este, por lo que obviamente MPM Event no es compatible con mod_php, habrá que usar php-fpm.

Multiprocesamiento tipo ITK (mpm-itk).

MPM ITK es un módulo nuevo y experimental cuyo funcionamiento es el mismo que el MPM Prefork, es decir, usa procesos hijo para su funcionamiento y no threads. La novedad de MPM ITK está en que permite asignar a cada host virtual (Virtualhost) un usuario del sistema, de esta forma en un servidor compartido que aloja varias webs de diferentes usuarios, estos usuarios no pueden interactuar con los archivos del resto de usuarios.

Este MPM es innovador pero está en fase experimental, de hecho no viene ni en la documentación oficial de Apache. Existen algunos módulos como suPHP o mod_ruid2 que nos permiten conseguir resultados similares a MPM ITK, yo personalmente uso mod_ruid2 y estoy contento con el.

¿Que Apache elegir? ¿Que módulo multiprocesamiento de Apache instalo?

Ahora que ya conocemos los diferentes tipos de Apache multiprocesamiento, os estaréis preguntando cual elegir o que versión MPM de Apache os conviene.

La decisión final es vuestra y en muchos casos se verá influenciada por vuestro nivel a la hora de manejar servidores Linux, pero yo intentaré daros una idea de lo que tenéis que tener en cuenta para elegir correctamente la versión de Apache que os conviene.

Factores que tenemos que tener en cuenta a la hora de elegir un módulo MPM de Apache:

  • Volumen de visitas o tráfico de nuestro servidor: si vamos manejar grandes volúmenes de visitas deberíamos descartar inmediatamente el uso de Apache Prefork. Debo añadir que si auxiliamos a Apache Prefork con un sistema de cache, como puede ser Varnish Cache podremos incrementar el volúmen de visitas que soporta nuestro servidor.
  • Tipo de contenido (dinámico o estático): otro factor importante a tener en cuenta es el tipo de contenido que queremos servir con Apache. Si se trata de contenido estático (imágenes, archivos comprimidos, etc…) sin duda MPM Worker o MPM Event son las elecciones acertadas. Si se trata de contenido dinámico tendremos que evaluar el resto de factores para determinar la mejor elección, ya que para contenido dinámico MPM Worker y MPM Event siguen necesitando menos recursos pero quizás algún otro factor es más determinante que el tipo de contenido.
  • Recursos del servidor: esta será nuestra limitación principal. Si disponemos de recursos de sobra igual podemos optar por una instalación de Apache Prefork y ahorrarnos dolores de cabeza con las configuraciones. Por el contrario, si andamos justos de recursos MPM Worker o MPM Event vuelven a ser las opciones preferidas.
  • Conocimientos específicos sobre servidores: los conocimientos que tenemos sobre instalación y configuración de Apache y PHP pueden ser un factor determinante puesto que mientras la instalación de MPM prefork con mod_php es muy sencilla, una instalación de MPM Worker o Event con php-fpm es más compleja.
  • Necesidades especificas: quizás nuestro proyecto tenga una necesidad muy específica y no nos permita emplear un MPM de Apache concreto. Por ejemplo podría ser que nuestro proyecto necesitase emplear un módulo que no es thread-safe, entonces nos veríamos obligados a emplear MPM Prefork.

Como ejemplo sólo puedo poner mi elección personal para un servidor con varios blogs WordPress y unas 1000 visitas diarias. Mi elección ha sido Apache MPM Prefork combinado con Varnish Cache. He tenido que optar por Prefork porque en mi servidor hay varios usuarios, cada uno con diferentes necesidades y webs, por lo que necesitaba la compatibilidad que ofrece Prefork y mod_php.

Antes de realizar una elección recomiendo realizar pruebas en algun VPS barato de pruebas y también pensar detenidamente como será vuestro proyecto para conocer las necesidades del mismo.

¿Cómo saber que tipo de Apache tengo instalado?

Si ya has instalado Apache en tu servidor Linux y necesitas saber que MPM de Apache estas usando, puedes emplear el siguiente comando:
apache2ctl -V
Este comando te mostrará mucha información en pantalla y en una de las líneas debería poner algo como:
Server MPM: Prefork
En este caso se usa el MPM Prefork.

Otra forma es emplear el comando:
apache2ctl -t -D DUMP_MODULES
Este comando nos muestra una lista con todos los módulos cargados y entre ellos podremos ver algo como:
mpm_prefork_module (static)
En este caso se cargó el MPM Prefork.

Para los usuarios de cPanel.

No soy un experto en cPanel, pero por lo que pude ver en la documentación de EasyApache tiene disponible las versiones Prefork, Worker y Event. En este aspecto cPanel os facilita mucho el trabajo de cambiar de un MPM a otro y su respectiva configuración de PHP.

Espero que os haya aclarado algunas dudas este artículo y como siempre no dudéis en preguntar a traves de los comentarios.