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


Esto es un Pregunta canónica acerca de cómo seleccionar el correcto Apache httpd MPM.

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á la mejor para un despliegue determinado?


243
2018-04-26 18:40


origen


Si usted está apoyando mod_php, entonces está haciendo prefork. - Zoredache
@Zoredache:? ella nunca mencionó PHP, e incluso si lo hubiera hecho, mod_php solo descartaría un evento. ¿O todavía te aferras a un comentario hecho por RL hace 8 años? El último error registrado en PHP relacionado con el apache con hilos fue en 2005. - symcbean
Lo siento, tengo que votar para cerrar esto, es una pregunta demasiado amplia para responder aquí. - symcbean
@symcbean Re: PHP and Threads: el núcleo de PHP es threadsafe en estos días, pero muchas otras cosas que encontrarás en las personas que compilan no lo son. Me han mordido tan recientemente como el año pasado, así que es mucho más que una "prueba (extensivamente) antes de confiar en ella en la producción". La situación aún ... - voretaq7
Dependiendo del sistema operativo que esté utilizando, es posible que ni siquiera tenga todas esas opciones disponibles con una instalación estándar. - John Gardeniers


Respuestas:


Hay una serie de Modulos MPM (Módulos de multiprocesamiento), pero con mucho los más utilizados (al menos en * nix plataformas) son los tres principales: prefork, workery 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 restricciones informáticas de la época a lo largo de su largo historial (en términos de software).


prefork

mpm_prefork es .. bueno .. es compatible con todo. Escoge 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 allí, listo para la acción, y sin necesidad de lidiar con el cálculo de hilos, en realidad es Más rápido que los MPM de subprocesos más modernos cuando solo está tratando con una sola solicitud a la vez, pero las solicitudes simultáneas sufren, ya que están hechas para esperar en línea hasta que el proceso del servidor sea gratuito. Además, al tratar de ampliar el recuento de los procesos secundarios previos a la perforación, podrá absorber fácilmente algo de RAM grave.

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

Usar si Necesita módulos que se rompan cuando se usan hilos, como mod_php. Incluso entonces, considere usar FastCGI y php-fpm.

No use si: Tus módulos no se romperán en el enhebrado.

worker

mpm_worker utiliza subprocesos, que es una gran ayuda para la concurrencia. El trabajador escinde algunos procesos secundarios, que a su vez escinden hilos secundarios; Al igual que en Prefork, algunos subprocesos de repuesto se mantienen listos, si es posible, para atender las conexiones entrantes. Este enfoque es mucho más amable con la RAM, ya que el recuento de subprocesos no tiene una incidencia directa en 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.

Usar si Estás en Apache 2.2 o 2.4 y ejecutas principalmente SSL.

No use si: Realmente no puedes equivocarte, a menos que necesites prefork para la compatibilidad.

Sin embargo, tenga en cuenta que las huellas se adjuntan a conexiones y no peticiones - lo que significa que una conexión de mantenimiento siempre mantiene una secuencia de espera hasta que se cierra (lo que puede durar mucho tiempo, dependiendo de su configuración). Es por eso que tenemos ...

event

mpm_event Es muy similar al trabajador, estructuralmente; se acaba de pasar del estado 'experimental' al 'estable' en Apache 2.4. La gran diferencia es que utiliza un subproceso dedicado para tratar con las conexiones vivas, y entrega las solicitudes a los subprocesos secundarios solo cuando realmente 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 son necesariamente todos activos a la vez, pero que realizan solicitudes ocasionales, y cuando los clientes pueden tener un tiempo de espera de larga vida útil prolongada.

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

Usar si Estás en Apache 2.4 y te gustan los hilos, pero no te gusta tener hilos que esperan conexiones inactivas. A todos les gustan los hilos!

No use si: No estás en Apache 2.4, o necesitas información previa para la compatibilidad.


En el mundo actual de Loris lento, AJAX y los navegadores a los que les gusta multiplexar 6 conexiones TCP (con keep-alive, por supuesto) a su servidor, la concurrencia es un factor importante para hacer que su servidor se amplíe y escala bien. La historia de Apache lo ha vinculado a este respecto, y aunque aún no está a la par con nginx o lighttpd en términos de uso o escala de recursos, está claro que el equipo de desarrollo está trabajando para construir un servidor web que aún sea relevante en el mundo de alta concurrencia de solicitud de hoy.


396
2018-04-27 02:27



-1: IME, worker solo reduce el tamaño de la huella de httpd en la región del 15% (IIRC Linux informa COW en RSS, lo que hace que parezca que usa mucha más memoria que antes). Hay una diferencia insignificante entre la huella del kernel para un proceso y un subproceso NPTL. Está muy lejos de la destrucción de la tierra. No entiendo por qué cree que esperar y asignar un subproceso es más eficiente en términos de programación que esperar / programar un proceso (pre-bifurcado). Tampoco lo que usted cree que tiene SSL en su conjunto. - symcbean
@symcbean Entonces, ¿estás diciendo que el 15% de uso de RAM no es significativo? Eso está bien, pero mi opinión sería de otra manera. Las afirmaciones de rendimiento concurrente no son mías. Ver aquí. Y la diferencia de SSL se explica claramente en la documentación del evento MPM: The improved connection handling does not yet work for certain connection filters, in particular SSL. For SSL connections, this MPM will fall back to the behaviour of the worker MPM and reserve one worker thread per connection. - Shane Madden♦
@ShaneMadden `y aunque en realidad aún no está a la par con nginx o lighttpd en términos de uso o escala de recursos` he tenido un apache piso para ambos sistemas. - Kelly Elton
@ShaneMadden con respecto al problema con SSL y el evento MPM: ¿Sabe si nginx maneja esto significativamente mejor que Apache? - DASKAjA
Parece que si compilas apache 2.4 sin saber acerca de los módulos mpm, viene con un módulo llamado event mpm module y funciona con mod_php7 (en este momento estoy investigando mpm porque apache2.4 está excediendo el límite de conexión mysql mientras que apache 2.2 con el mismo servidor mysql es no) - BioHazard


Depende principalmente de los módulos de Apache que quieras usar. Creo que worker es generalmente la opción predeterminada, pero algunos módulos (más antiguos) requieren bifurcación y dependen de la ejecución previa.

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


5
2018-04-26 19:32





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

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

En pocas palabras: si estás en 2.4 y necesitas httpd como proxy inverso (despachador) por lo que su elección es una Evento MPM


5
2018-06-21 13:10





A partir de febrero de 2018, la documentación de Apache 2.4 para el evento MPM indica que el uso de Apache como un proxy mantendrá la "mejor gestión de la conexión" desde la versión 2.4.24 de funcionar según lo diseñado. Ver el Limitaciones sección.

El problema es que, como proxy, el trabajador no puede decir 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 un proxy. No me queda realmente claro si hay ventajas para el modelo de evento en un entorno proxy, pero tal vez las haya.


3
2018-02-14 15:01