Comment sélectionner le MPM Apache à utiliser?
Il s'agit d'une question canonique sur la sélection du bon MPM Apache httpd.
Je suis un peu confus entre les différents MPM proposés par Apache - 'travailleur', 'événement', 'préfork', etc.
Quelles sont les principales différences entre elles et comment puis-je décider laquelle sera la meilleure pour un déploiement donné?
Il existe un certain nombre de modules MPM (modules multi-traitements), mais de loin les plus utilisés (au moins sur les plates-formes * nix) sont les trois principaux: prefork, worker et event. Essentiellement, ils représentent l'évolution du serveur Web Apache et les différentes façons dont le serveur a été conçu pour gérer les requêtes HTTP dans les contraintes informatiques de l'époque au cours de sa longue histoire (en termes de logiciel).
prefork
mpm_prefork est .. eh bien .. c'est compatible avec tout. Il génère un certain nombre de processus enfants pour traiter les demandes, et les processus enfants ne servent qu'une seule demande à la fois. Parce que le processus du serveur est là, prêt à l'action et n'a pas besoin de traiter le marshaling des threads, il est en fait plus rapide que les MPM threadés plus modernes lorsque vous ne traitez qu'une seule demande à la fois - mais les demandes simultanées souffrent, car elles sont faites pour faire la queue jusqu'à ce qu'un processus serveur soit libre. De plus, en essayant d'augmenter le nombre de processus enfants pré-fourche, vous aspirerez facilement de la RAM sérieuse.
Il n'est probablement pas conseillé d'utiliser prefork sauf si vous avez besoin d'un module qui n'est pas sûr pour les threads.
Utilisez si: Vous avez besoin de modules qui se cassent lorsque des threads sont utilisés, comme mod_php. Même dans ce cas, envisagez d'utiliser FastCGI et php-fpm.
Ne pas utiliser si: Vos modules ne se casseront pas dans le filetage.
worker
mpm_worker utilise le filetage - ce qui est d'une grande aide pour la concurrence. Worker détourne certains processus enfants, qui à leur tour désactive les threads enfants; de la même manière que prefork, certains threads de rechange sont maintenus prêts, si possible, pour desservir les connexions entrantes. Cette approche est beaucoup plus douce sur la RAM, car le nombre de threads n'a pas d'incidence directe sur l'utilisation de la mémoire comme le fait le nombre de serveurs dans prefork. Il gère également la concurrence beaucoup plus facilement, car les connexions doivent simplement attendre un thread gratuit (qui est généralement disponible) au lieu d'un serveur de rechange dans prefork.
À utiliser si: Vous utilisez Apache 2.2 ou 2.4 et vous utilisez principalement SSL.
Ne pas utiliser si: Vous ne pouvez vraiment pas vous tromper, sauf si vous avez besoin de préfork pour la compatibilité.
Cependant, notez que les marches sont attachées à connexions et non requêtes - ce qui signifie qu'une connexion persistante conserve toujours la prise d'un thread jusqu'à ce qu'il soit fermé (ce qui peut être long, selon votre configuration). C'est pourquoi nous avons ..
event
mpm_event est très similaire au travailleur, structurellement; il vient d'être déplacé du statut "expérimental" à "stable" dans Apache 2.4. La grande différence est qu'il utilise un thread dédié pour gérer les connexions maintenues en vie et transmet les requêtes aux threads enfants uniquement lorsqu'une demande a été réellement effectuée (permettant à ces threads de se libérer immédiatement après la fin de la demande). C'est idéal pour la simultanéité de clients qui ne sont pas nécessairement tous actifs à la fois, mais qui font des demandes occasionnelles, et lorsque les clients peuvent avoir un long délai d'attente.
L'exception ici concerne les connexions SSL; dans ce cas, il se comporte de manière identique à travailleur (en collant une connexion donnée à un thread donné jusqu'à la fermeture de la connexion).
Utilisez si: 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 pas utiliser si: Vous n'êtes pas sur Apache 2.4, ou vous avez besoin de préfork pour la compatibilité.
Dans le monde actuel de slowloris , AJAX et des navigateurs qui aiment multiplexer 6 TCP (avec maintien en vie, bien sûr) à votre serveur, la concurrence est un élément important facteur de rendre votre serveur à l'échelle et à bien évoluer. L'histoire d'Apache l'a lié à cet égard, et bien qu'il ne soit vraiment toujours pas à la hauteur des goûts de nginx ou lighttpd en termes d'utilisation des ressources ou d'échelle, il est clair que l'équipe de développement travaille à la création d'un serveur Web toujours pertinent dans le monde actuel à forte demande de concurrence.
Voici une bonne explication de la façon dont cela fonctionne avec les gifs:
https://www.datadoghq.com/blog/monitoring-Apache-web-server-performance/
En bref: si vous 2.4 et vous avez besoin de httpd comme proxy inverse (répartiteur) donc votre choix est un MPM d'événement
Depuis février 2018, la documentation Apache 2.4 pour Event MPM indique que l'utilisation d'Apache comme proxy empêchera la "gestion améliorée des connexions" depuis 2.4.24 de fonctionner comme prévu. Voir la section Limitations .
Le problème est qu'en tant que proxy, le travailleur ne peut pas dire où se trouve la fin de la réponse et sera obligé d'attendre jusqu'à ce que la réponse entière soit vue avant de rendre le contrôle à l'auditeur.
Pour cette raison, il semble que l'utilisation du modèle Worker peut être préférable lorsque Apache est utilisé comme proxy. Il n'est pas vraiment clair pour moi s'il y a des avantages au modèle d'événement dans un environnement proxy, mais peut-être qu'il y en a.
Cela dépend principalement des modules Apache que vous souhaitez utiliser. Je pense que travailleur est généralement le choix par défaut, mais certains modules (plus anciens) nécessitent une fourche et dépendent de la pré-fourche.
Si vous n'avez aucune préférence, je vous recommande de choisir la dépendance préférée de votre distribution de système d'exploitation. Ubuntu, par exemple, installera par défaut mpm-worker lorsque vous installerez Apache2.