Serveur Apache HTTP Version 2.4
Serveur Apache HTTP Version 2.4
| 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� 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 worker et
r�serve un thread par connexion. Tous les modules fournis
avec le serveur sont compatibles avec le MPM event.
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'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, 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 � :
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".