Le module multi-processus (MPM)
Pour utiliser le MPM --with-mpm=event
aux arguments du script
Ce MPM essaie de résoudre le 'problème keep alive' de HTTP.
Lorsqu'un client a soumis une première requête, il peut garder la
connexion ouverte, et envoyer les requêtes suivantes en utilisant le
même socket. Ceci permet de réduire de manière significative la
surcharge due à la création de connexions TCP.
Cependant, le serveur HTTP Apache
mobilise en principe à cet effet un processus/thread enfant en
attente des données du client, ce qui amène son propre lot
d'inconvénients. Pour résoudre ce problème,
Le gestionnaire de connexion amélioré peut ne pas
fonctionner pour les filtres de connexion qui se déclarent eux-mêmes
comme incompatibles avec le MPM event. Dans ce cas, le MPM event
adopte le comportement du MPM
Une restriction similaire existe pour les requêtes qui utilisent un filtre en sortie qui doit lire et/ou modifier l'ensemble du corps de réponse, comme dans le cas de mod_ssl, mod_deflate, ou mod_include. Si la connexion avec le client se bloque pendant que le filtre traite les données, et si la quantité de données générée par ce filtre est trop importante pour être mise en tampon mémoire, le thread utilisé pour la requête n'est pas libéré pendant que httpd attend que toutes les données restantes aient été transmises au client.
Le MPM présuppose que l'implémentation apr_pollset
sous-jacente est raisonnablement sûre du point de vue des threads.
Ceci permet au MPM d'éviter un verrouillage de haut niveau excessif,
ou de devoir activer le thread en écoute afin de lui envoyer un
socket keep alive. Tout ceci n'est actuellement compatible qu'avec
KQueue et EPoll.
Ce MPM dépend des opérations atomiques compare-and-swap
d'--enable-nonportable-atomics=yes
aux arguments du
script
Ce MPM ne fonctionne pas de manière optimale sur les plates-formes plus anciennes qui ne gèrent pas correctement les threads, mais ce problème est sans objet du fait du prérequis concernant EPoll ou KQueue.
libkse
(voir man libmap.conf
).glibc
a été compilée
avec le support pour EPoll.Le MPM event gère certaines connexions de manière asynchrone ; dans ce cas, les threads traitant la requête sont alloués selon les besoins et pour de courtes périodes. Dans les autres cas, un thread est réservé par connexion. Ceci peut conduire à des situations où tous les threads sont saturés et où aucun thread n'est capable d'effectuer de nouvelles tâches pour les connexions asynchrones établies.
Pour minimiser les effets de ce problème, le MPM event utilise deux méthodes : tout d'abord, il limite le nombre de connexions simultanées par thread en fonction du nombre de processus inactifs. Ensuite, si tous les processus sont occupés, il ferme des connexions permanentes, même si la limite de durée de la connexion n'a pas été atteinte. Ceci autorise les clients concernés à se reconnecter à un autre processus possèdant encore des threads disponibles.
Cette directive permet de personnaliser finement la limite du nombre de connexions par thread. Un processus n'acceptera de nouvelles connexions que si le nombre actuel de connexions (sans compter les connexions à l'état "closing") est inférieur à :
En d'autres termes, le nombre maximum de connexions simultanées sera :
(
La directive
La directive