¿Cómo selecciono qué MPM de Apache usar?

Esta es una pregunta canónica sobre la selección del Apache httpd MPM correcto.

Estoy un poco confundido entre los diferentes MPM ofrecidos por Apache: 'trabajador', 'evento', 'prefork', etc.

¿Cuáles son las principales diferencias entre ellos y cómo puedo decidir cuál será el mejor para una implementación determinada?

Hay una serie de módulos MPM (Módulos Multi-Processing), pero con mucho, el más ampliamente usado (al menos en las plataformas * nix) son los tres principales: prefork, worker, y event. Esencialmente, representan la evolución del servidor web Apache y las diferentes formas en que el servidor se ha creado para manejar las solicitudes HTTP dentro de las limitaciones informáticas del tiempo a lo largo de su largo historial (en términos de software).

prefork

mpm_preforkes ... bueno ... es compatible con todo. Escinde una serie de procesos secundarios para atender solicitudes, y los procesos secundarios solo sirven una solicitud a la vez. Debido a que tiene el proceso del servidor sentado allí, listo para la acción, y no necesita lidiar con la organización de subprocesos, en realidad es más rápido que los MPMs de subprocesos más modernos cuando solo se trata de una sola solicitud a la vez, pero las solicitudes concurrentes sufren, ya que están hechos para esperar en línea hasta que el proceso de un servidor sea gratuito. Además, al intentar escalar en el recuento de procesos secundarios prefork, fácilmente absorberá un poco de RAM grave.

Probablemente no sea aconsejable usar prefork a menos que necesite un módulo que no sea seguro para subprocesos.

Use if: necesita módulos que se rompan cuando se usan hilos, como mod_php. Incluso entonces, considere usar FastCGI y php-fpm.

No use si: Sus módulos no se romperán en subprocesos.

worker

mpm_workerutiliza subprocesos, que es una gran ayuda para la concurrencia. El trabajador separa algunos procesos secundarios, que a su vez generan subprocesos secundarios; similar a prefork, algunos hilos de repuesto se mantienen listos si es posible, para dar servicio a las conexiones entrantes. Este enfoque es mucho más amable en RAM, ya que el recuento de subprocesos no tiene una relación directa con el uso de la memoria como lo hace el recuento de servidores en prefork. También maneja la concurrencia mucho más fácilmente, ya que las conexiones solo necesitan esperar un subproceso libre (que generalmente está disponible) en lugar de un servidor de repuesto en prefork.

Use si: está en Apache 2.2 o 2.4 y está ejecutando principalmente SSL.

No use if: Realmente no puede salir mal, a menos que necesite prefork para compatibilidad.

Sin embargo, tenga en cuenta que las bandas de rodadura están unidas a conexiones y no a solicitudes , lo que significa que una conexión de mantenimiento siempre mantiene un hilo hasta que se cierra (que puede ser mucho tiempo, dependiendo de su configuración). Por eso tenemos ...

event

mpm_eventes muy similar al trabajador, estructuralmente; acaba de pasar del estado 'experimental' al 'estable' en Apache 2.4. La gran diferencia es que utiliza un subproceso dedicado para tratar las conexiones mantenidas vivas, y entrega las solicitudes a subprocesos secundarios solo cuando se ha realizado una solicitud (permitiendo que esos subprocesos se liberen inmediatamente después de que se complete la solicitud). Esto es excelente para la concurrencia de clientes que no necesariamente están todos activos a la vez, pero que hacen solicitudes ocasionales y cuando los clientes pueden tener un tiempo de espera prolongado para mantenerse con vida.

La excepción aquí es con conexiones SSL; en ese caso, se comporta de manera idéntica al trabajador (pegando una conexión dada a un hilo dado hasta que se cierra la conexión).

Use if: está en Apache 2.4 y le gustan los hilos, pero no le gusta tener hilos esperando conexiones inactivas. ¡A todos les gustan los hilos!

No use si: No está en Apache 2.4, o necesita prefork para compatibilidad.

En el mundo actual de slowloris , AJAX y navegadores a los que les gusta multiplexar 6 conexiones TCP (con mantener vivo, por supuesto) a su servidor, la concurrencia es un factor importante para que su servidor escale y escale bien. La historia de Apache lo ha atado a este respecto, y aunque en realidad aún no está a la altura de los gustos de nginx o lighttpd en términos de uso de recursos o escala, está claro que el equipo de desarrollo está trabajando para construir un servidor web que todavía sea relevante en el mundo actual de alta concurrencia de solicitudes.

Aquí hay una buena explicación de cómo funciona con los gifs:

https://www.datadoghq.com/blog/monitoring-apache-web-server-performance/

Brevemente: si tiene 2.4 y necesita httpd como proxy inverso (despachador), su elección es un MPM de evento

A partir de febrero de 2018, la documentación de Apache 2.4 para Event MPM establece que el uso de Apache como proxy evitará que el "manejo mejorado de la conexión" desde 2.4.24 funcione como fue diseñado. Vea la sección de Limitaciones .

El problema es que, como proxy, el trabajador no puede saber dónde está el final de la respuesta y se verá obligado a esperar hasta que se vea la respuesta completa antes de devolver el control al oyente.

Por esta razón, parece que usar el modelo Worker puede ser mejor para cuando apache se usa como proxy. Realmente no me queda claro si hay ventajas para el modelo de eventos en un entorno proxy, pero tal vez sí.

Principalmente depende de qué módulos de Apache desea usar. Creo que trabajador es generalmente la opción predeterminada, pero algunos módulos (más antiguos) requieren bifurcación y dependen de prefork.

Si no tiene preferencias, le recomiendo que elija la dependencia preferida de su distribución del sistema operativo. Ubuntu, por ejemplo, instalará por defecto mpm-worker cuando instale Apache2.