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
, worker
et 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).
mpm_prefork
est .. 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.
mpm_worker
utilise 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 ..
mpm_event
est 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.