Comment sélectionner le MPM Apache à utiliser?

261

Ceci est une question canonique sur la sélection du bon Apache httpd MPM.

Je suis un peu confus entre les différents MPM proposés par Apache - "travailleur", "événement", "prefork", etc.

Quelles sont les principales différences entre elles et comment puis-je décider laquelle sera la meilleure pour un déploiement donné?

apache-2.2 httpd mpm-worker mpm-prefork Tiffany Walker
la source
4
Si vous supportez mod_php, alors vous utilisez prefork.
Zoredache
6
@ Zoredache:? elle n'a jamais mentionné PHP, et même si elle l'avait fait, mod_php ne ferait qu'exclure un événement. Ou êtes-vous toujours accroché à une remarque faite par RL il y a 8 ans? Le dernier bogue enregistré en PHP lié à threadé apache était en 2005.
symcbean
2
Désolé - je dois voter pour fermer ceci - est une question beaucoup trop large pour répondre ici.
symcbean
1
@symcbean Re: PHP and Threads - Le coeur de PHP est thread-safe, mais beaucoup d'autres choses dans lesquelles les gens compilent ne le sont pas. J'ai été mordu aussi récemment que l'année dernière, donc c'est toujours un "test (approfondi) avant de
m'en remettre
Selon le système d'exploitation que vous utilisez, il se peut que toutes les options disponibles ne soient pas disponibles avec une installation standard.
John Gardeniers

Réponses:

415

Il y a un certain nombre de modules MPM (Modules Multi-Processing), mais de loin le plus largement utilisé (au moins sur les plates - formes * nix) sont les trois principaux: prefork, workeret event. Ils représentent essentiellement l'évolution du serveur Web Apache et les différentes manières dont le serveur a été conçu pour traiter les demandes HTTP dans le respect des contraintes informatiques de son époque (en termes logiciels).

prefork

mpm_preforkest .. bien .. c'est compatible avec tout. Il essuie un certain nombre de processus enfants pour répondre aux demandes, et les processus enfants ne servent qu'une demande à la fois. Parce que le processus serveur est à la fois prêt à passer à l'action et qu'il n'est pas nécessaire de gérer le marshaling de threads, il est en fait plus rapide que les MPM à thread plus modernes, lorsque vous ne traitez qu'une seule requête à la fois, mais que les requêtes simultanées souffrent, puisqu'ils sont faits pour attendre en ligne jusqu'à ce qu'un processus de serveur est libre. En outre, si vous essayez d'augmenter le nombre de processus enfants pré-forkés, vous absorberez facilement une RAM importante.

Il est probablement déconseillé d’utiliser Prefork sauf si vous avez besoin d’un module qui n’est pas thread-safe.

Utilisez si: Vous avez besoin de modules qui se cassent lorsque les threads sont utilisés, comme mod_php. Même alors, envisagez d’utiliser FastCGI et php-fpm.

Ne pas utiliser si: vos modules ne se briseront pas.

worker

mpm_workerutilise thread - ce qui est une aide précieuse pour la concurrence. Worker supprime certains processus enfants, qui à leur tour suppriment les threads enfants; À l'instar de Prefork, certains threads de réserve sont tenus prêts, si possible, afin de gérer les connexions entrantes. Cette approche est beaucoup plus douce pour la RAM, car le nombre de threads n’a pas d’incidence directe sur l’utilisation de la mémoire, contrairement au nombre de serveurs dans Prefork. Il gère également beaucoup plus facilement les accès simultanés, car les connexions doivent simplement attendre un thread libre (généralement disponible) au lieu d’un serveur de réserve dans Prefork.

Utilisez si: Vous êtes sur Apache 2.2 ou 2.4 et vous utilisez principalement SSL.

Ne l'utilisez pas si: Vous ne pouvez vraiment pas vous tromper, à moins que vous ayez besoin de forfork pour compatibilité.

Cependant, notez que les bandes de roulement sont attachées à des connexions et non à des requêtes - ce qui signifie qu'une connexion persistante garde toujours un thread en attente jusqu'à sa fermeture (ce qui peut être long, selon votre configuration). C'est pourquoi nous avons ..

event

mpm_eventest très semblable au travailleur, structurellement; il vient d'être déplacé du statut 'expérimental' au statut 'stable' dans Apache 2.4. La grande différence est qu’elle utilise un thread dédié pour traiter les connexions gardées en vie et ne transmet les requêtes aux threads enfants qu’une fois la demande effectuée (ce qui permet à ces threads de se libérer immédiatement après l’achèvement de la demande). Ceci est idéal pour les clients simultanés qui ne sont pas nécessairement tous actifs à la fois, mais font des requêtes occasionnelles, et lorsque les clients peuvent avoir un long délai de maintien en vie.

La seule exception concerne les connexions SSL. dans ce cas, il se comporte de manière identique à worker (coller une connexion donnée sur un thread donné jusqu'à la fermeture de la connexion).

Utilisez if: Vous êtes sur Apache 2.4 et aimez les threads, mais vous n'aimez pas avoir des threads en attente de connexions inactives. Tout le monde aime les fils!

Ne l'utilisez pas si: Vous n'êtes pas sur Apache 2.4, ou vous avez besoin de prefork pour la compatibilité.

Dans le monde actuel de slowloris , AJAX et les navigateurs qui aiment multiplexer 6 connexions TCP (avec Keep-Alive, bien sûr) sur votre serveur, la simultanéité est un facteur important pour bien faire évoluer votre serveur. L’histoire d’Apache a fait la différence à cet égard, et même s’il n’est pas encore à la hauteur de nginx ou de lighttpd en termes d’utilisation ou d’ampleur des ressources, il est clair que l’équipe de développement travaille à la création d’un serveur Web toujours pertinent. dans le monde actuel à haute demande-concurrence.

Shane Madden
la source
3
-1: IME, worker ne réduit que de 15% la taille de l'empreinte httpd (le rapport IIRC Linux indique COW dans RSS, ce qui donne l'impression que le pré-fork utilise beaucoup plus de mémoire). La différence entre l'empreinte du noyau d'un processus et celle d'un thread NPTL est négligeable. C'est loin de la destruction totale. Je ne comprends pas pourquoi vous pensez que l'attente et l'allocation d'un thread sont plus efficaces en termes de planification que l'attente / la planification d'un processus (pré-forké). Ni ce que vous pensez de SSL a dans l'ensemble elle-bang.
symcbean
9
@symcbean Vous dites donc que 15% d'utilisation de RAM n'est pas significatif? C'est bien, mais mon avis serait autrement. Les revendications de performances de concurrence ne sont pas les miennes. Voir ici . Et la différence SSL est clairement expliquée dans la documentation de l'événement 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
3
@ShaneMadden `et bien que ce ne soit pas encore à la hauteur de nginx ou de lighttpd en termes d’utilisation des ressources ou d’échelle’ j’ai eu Apache Floor ces deux systèmes.
Kelly Elton
@ShaneMadden en ce qui concerne le problème avec SSL et l'événement MPM: Savez-vous si nginx gère cela beaucoup mieux qu'apache?
DASKAjA
Il semble que si vous compilez apache 2.4 sans connaître les modules mpm, il est livré avec le module event mpm module et fonctionne avec mod_php7 (pour le moment, je suis à la recherche de mpm car apache2.4 dépasse la limite de connexion mysql, alors qu'apache 2.2 avec le même serveur mysql pas)
BioHazard
8

Voici une bonne explication de son fonctionnement avec les gifs:

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

En bref: si vous utilisez la version 2.4 et que vous avez besoin de httpd en tant que proxy inverse (répartiteur), votre choix est donc un événement MPM.

Yura
la source
Même si on utilise SSL? J'utilise apache en tant que proxy et activateur SSL sur un site Web non SSL.
Bokan
@bokan ressemble à oui, c'est le meilleur, mais de toute façon, le proxy est limité pour SSL
Yura
Wow ~ Le blog est bien meilleur que la réponse acceptée, et les gifs sont merveilleux! Thankssss. Tu as sauvé ma journée.
Rick
6

Depuis février 2018, la documentation d'Apache 2.4 pour Event MPM indique que l'utilisation d'Apache en tant que proxy empêchera la "gestion de connexion améliorée" depuis 2.4.24 de fonctionner comme prévu. Voir la section Limitations .

Le problème est que, en tant que mandataire, l'agent ne peut pas dire où se trouve la fin de la réponse et sera obligé d'attendre jusqu'à ce que l'intégralité de la réponse soit visible avant de rendre le contrôle à l'auditeur.

Pour cette raison, il semble que l’utilisation du modèle Worker conviendrait mieux lorsque Apache est utilisé comme proxy. Il n’est pas vraiment clair pour moi si le modèle d’événement présente des avantages dans un environnement de proxy, mais peut-être qu’il en existe.

EtOu
la source
5

Cela dépend principalement des modules Apache que vous souhaitez utiliser. Je pense que worker est généralement le choix par défaut, mais certains modules (plus anciens) nécessitent un forking et dépendent de prefork.

Si vous n'avez pas de préférences, je vous recommande d'utiliser la dépendance préférée de votre distribution de système d'exploitation. Ubuntu, par exemple, installera par défaut mpm-worker lors de l’installation d’Apache2.

Jeroen
la source