Serveur Apache HTTP Version 2.3
Serveur Apache HTTP Version 2.3
| Description: | Une variante du MPM worker conçue pour ne
mobiliser des threads que pour les connexions en cours de traitement |
|---|---|
| Statut: | MPM |
| Identificateur de Module: | mpm_event_module |
| Fichier Source: | event.c |
Le module multi-processus (MPM) event est conçu
pour permettre le traitement d'un nombre accru de requêtes
simultanées en déléguant certaines tâches à des threads de support,
libérant par là-même le thread principal et lui permettant de
traiter les nouvelles requêtes. Il s'inspire du MPM
worker qui implémente un serveur hybride
multi-processus/multi-threads. Les directives de configuration à
l'exécution sont identiques à celles du MPM
worker.
Pour utiliser le MPM event, ajoutez
--with-mpm=event aux arguments du script
configure lorsque vous compilez le programme
httpd.
AsyncRequestWorkerFactor
CoreDumpDirectory EnableExceptionHook Group Listen ListenBacklog MaxConnectionsPerChild MaxMemFree MaxRequestWorkers MaxSpareThreads MinSpareThreads PidFile ScoreBoardFile SendBufferSize ServerLimit StartServers ThreadLimit ThreadsPerChild ThreadStackSize User
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, event
utilise un thread dédié qui gère les sockets en
écoute, tous les sockets en état Keep Alive, et les
sockets où les filtres gestionnaires et de protocole ont
fait leur travail et pour lesquels la seule chose restant à faire
consiste à envoyer les données au client. La page d'état de
mod_status montre les connexions qui se trouvent
dans les situations mentionnées.
Le gestionnaire de connexion amélioré ne fonctionne pas encore
pour certains filtres de connexion, et en particulier SSL. Pour les
connexions SSL, ce MPM réadopte le comportement du MPM
worker et réserve un thread par connexion.
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'APR pour la synchronisation des threads. Si
vous compilez pour une plate-forme x86 et n'avez pas besoin du
support 386, ou si vous compilez pour une plate-forme SPARC et
n'avez pas besoin du support pre-UltraSPARC, ajoutez
--enable-nonportable-atomics=yes aux arguments du
script configure. Ceci permettra à APR
d'implémenter les opérations atomiques en utilisant des instructions
performantes indisponibles avec les processeurs plus
anciens.
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.| Description: | Limite le nombre de connexions simultanées par thread |
|---|---|
| Syntaxe: | AsyncRequestWorkerFactor facteur |
| Défaut: | 2 |
| Contexte: | configuration du serveur |
| Statut: | MPM |
| Module: | event |
| Compatibilité: | Disponible depuis la version 2.3.13 |
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 (la plupart du temps pour les connexions SSL), 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 est inférieur à :
ThreadsPerChild +
(AsyncRequestWorkerFactor *
nombre de threads inactifs)
En d'autres termes, le nombre maximum de connexions simultanées sera :
(AsyncRequestWorkerFactor + 1) *
MaxRequestWorkers
La directive MaxRequestWorkers se nommait
MaxClients avant la version 2.3.13. La valeur
ci-dessus montre que cet ancien nom ne correspondait pas à sa
signification exacte pour le MPM event.
La directive AsyncRequestWorkerFactor
accepte des valeurs d'argument de type non entier, comme "1.5".