2 <!DOCTYPE modulesynopsis SYSTEM "../style/modulesynopsis.dtd">
3 <?xml-stylesheet type="text/xsl" href="../style/manual.fr.xsl"?>
4 <!-- English Revision : 1514214 -->
5 <!-- French translation : Lucien GENTIS -->
6 <!-- Reviewed by : Vincent Deffontaines -->
9 Licensed to the Apache Software Foundation (ASF) under one or more
10 contributor license agreements. See the NOTICE file distributed with
11 this work for additional information regarding copyright ownership.
12 The ASF licenses this file to You under the Apache License, Version 2.0
13 (the "License"); you may not use this file except in compliance with
14 the License. You may obtain a copy of the License at
16 http://www.apache.org/licenses/LICENSE-2.0
18 Unless required by applicable law or agreed to in writing, software
19 distributed under the License is distributed on an "AS IS" BASIS,
20 WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
21 See the License for the specific language governing permissions and
22 limitations under the License.
25 <modulesynopsis metafile="event.xml.meta">
27 <description>Une variante du MPM <module>worker</module> conçue pour ne
28 mobiliser des threads que pour les connexions en cours de traitement</description>
30 <sourcefile>event.c</sourcefile>
31 <identifier>mpm_event_module</identifier>
34 <p>Le module multi-processus (MPM) <module>event</module> est conçu
35 pour permettre le traitement d'un nombre accru de requêtes
36 simultanées en déléguant certaines tâches à des threads de support,
37 libérant par là-même le thread principal et lui permettant de
38 traiter les nouvelles requêtes. Il s'inspire du MPM
39 <module>worker</module> qui implémente un serveur hybride
40 multi-processus/multi-threads. Les directives de configuration à
41 l'exécution sont identiques à celles du MPM
42 <module>worker</module>.</p>
44 <p>Pour utiliser le MPM <module>event</module>, ajoutez
45 <code>--with-mpm=event</code> aux arguments du script
46 <program>configure</program> lorsque vous compilez le programme
47 <program>httpd</program>.</p>
51 <seealso><a href="worker.html">Le MPM worker</a></seealso>
53 <section id="how-it-works"><title>Comment tout cela fonctionne</title>
54 <p>Ce MPM essaie de résoudre le 'problème keep alive' de HTTP.
55 Lorsqu'un client a soumis une première requête, il peut garder la
56 connexion ouverte, et envoyer les requêtes suivantes en utilisant le
57 même socket. Ceci permet de réduire de manière significative la
58 surcharge due à la création de connexions TCP.
59 Cependant, le serveur HTTP Apache
60 mobilise en principe à cet effet un processus/thread enfant en
61 attente des données du client, ce qui amène son propre lot
62 d'inconvénients. Pour résoudre ce problème, <module>event</module>
63 utilise un thread dédié qui gère les sockets en
64 écoute, tous les sockets en état Keep Alive, et les
65 sockets où les filtres gestionnaires et de protocole ont
66 fait leur travail et pour lesquels la seule chose restant à faire
67 consiste à envoyer les données au client. La page d'état de
68 <module>mod_status</module> montre les connexions qui se trouvent
69 dans les situations mentionnées.</p>
71 <p>Le gestionnaire de connexion amélioré peut ne pas
72 fonctionner pour les filtres de connexion qui se déclarent eux-mêmes
73 comme incompatibles avec le MPM event. Dans ce cas, le MPM event
74 adopte le comportement du MPM <module>worker</module> et
75 réserve un thread par connexion. Tous les modules fournis
76 avec le serveur sont compatibles avec le MPM event.</p>
78 <p>Une restriction similaire existe pour les requêtes qui utilisent
79 un filtre en sortie qui doit lire et/ou modifier l'ensemble du corps
80 de réponse, comme dans le cas de mod_ssl, mod_deflate, ou
81 mod_include. Si la connexion avec le client se bloque pendant que le
82 filtre traite les données, et si la quantité de données générée par
83 ce filtre est trop importante pour être mise en tampon mémoire, le
84 thread utilisé pour la requête n'est pas libéré pendant que httpd
85 attend que toutes les données restantes aient été transmises au
88 <p>Le MPM présuppose que l'implémentation <code>apr_pollset</code>
89 sous-jacente est raisonnablement sûre du point de vue des threads.
90 Ceci permet au MPM d'éviter un verrouillage de haut niveau excessif,
91 ou de devoir activer le thread en écoute afin de lui envoyer un
92 socket keep alive. Tout ceci n'est actuellement compatible qu'avec
96 <section id="requirements"><title>Prérequis</title>
97 <p>Ce MPM dépend des opérations atomiques compare-and-swap
98 d'<glossary>APR</glossary> pour la synchronisation des threads. Si
99 vous compilez pour une plate-forme x86 et n'avez pas besoin du
100 support 386, ou si vous compilez pour une plate-forme SPARC et
101 n'avez pas besoin du support pre-UltraSPARC, ajoutez
102 <code>--enable-nonportable-atomics=yes</code> aux arguments du
103 script <program>configure</program>. Ceci permettra à APR
104 d'implémenter les opérations atomiques en utilisant des instructions
105 performantes indisponibles avec les processeurs plus
108 <p>Ce MPM ne fonctionne pas de manière optimale sur les
109 plates-formes plus anciennes qui ne gèrent pas correctement les
110 threads, mais ce problème est sans objet du fait du prérequis
111 concernant EPoll ou KQueue.</p>
115 <li>Pour utiliser ce MPM sous FreeBSD, la version 5.3 ou
116 supérieure de ce système est recommandée. Il est cependant
117 possible d'exécuter ce MPM sous FreeBSD 5.2.1 si vous utilisez
118 <code>libkse</code> (voir <code>man libmap.conf</code>).</li>
120 <li>Pour NetBSD, il est recommander d'utiliser la version 2.0 ou
121 supérieure.</li>
123 <li>Pour Linux, un noyau 2.6 est recommandé. Il faut aussi
124 s'assurer que votre version de <code>glibc</code> a été compilée
125 avec le support pour EPoll.</li>
130 <directivesynopsis location="mpm_common"><name>CoreDumpDirectory</name>
132 <directivesynopsis location="mpm_common"><name>EnableExceptionHook</name>
134 <directivesynopsis location="mod_unixd"><name>Group</name>
136 <directivesynopsis location="mpm_common"><name>Listen</name>
138 <directivesynopsis location="mpm_common"><name>ListenBacklog</name>
140 <directivesynopsis location="mpm_common"><name>SendBufferSize</name>
142 <directivesynopsis location="mpm_common"><name>MaxRequestWorkers</name>
144 <directivesynopsis location="mpm_common"><name>MaxMemFree</name>
146 <directivesynopsis location="mpm_common"><name>MaxConnectionsPerChild</name>
148 <directivesynopsis location="mpm_common"><name>MaxSpareThreads</name>
150 <directivesynopsis location="mpm_common"><name>MinSpareThreads</name>
152 <directivesynopsis location="mpm_common"><name>PidFile</name>
154 <directivesynopsis location="mpm_common"><name>ScoreBoardFile</name>
156 <directivesynopsis location="mpm_common"><name>ServerLimit</name>
158 <directivesynopsis location="mpm_common"><name>StartServers</name>
160 <directivesynopsis location="mpm_common"><name>ThreadLimit</name>
162 <directivesynopsis location="mpm_common"><name>ThreadsPerChild</name>
164 <directivesynopsis location="mpm_common"><name>ThreadStackSize</name>
166 <directivesynopsis location="mod_unixd"><name>User</name>
170 <name>AsyncRequestWorkerFactor</name>
171 <description>Limite le nombre de connexions simultanées par thread</description>
172 <syntax>AsyncRequestWorkerFactor <var>facteur</var></syntax>
174 <contextlist><context>server config</context> </contextlist>
175 <compatibility>Disponible depuis la version 2.3.13</compatibility>
178 <p>Le MPM event gère certaines connexions de manière asynchrone ;
179 dans ce cas, les threads traitant la requête sont alloués selon les
180 besoins et pour de courtes périodes. Dans les autres cas, un
181 thread est réservé par
182 connexion. Ceci peut conduire à des situations où tous les threads
183 sont saturés et où aucun thread n'est capable d'effectuer de
184 nouvelles tâches pour les connexions asynchrones établies.</p>
186 <p>Pour minimiser les effets de ce problème, le MPM event utilise
187 deux méthodes : tout d'abord, il limite le nombre de connexions
188 simultanées par thread en fonction du nombre de processus
189 inactifs. Ensuite, si tous les processus sont occupés, il ferme des
190 connexions permanentes, même si la limite de durée de la connexion
191 n'a pas été atteinte. Ceci autorise les clients concernés à se
192 reconnecter à un autre processus possèdant encore des threads
195 <p>Cette directive permet de personnaliser finement la limite du
196 nombre de connexions par thread. Un processus n'acceptera de
197 nouvelles connexions que si le nombre actuel de connexions (sans
198 compter les connexions à l'état "closing") est
199 inférieur à :</p>
201 <p class="indent"><strong>
202 <directive module="mpm_common">ThreadsPerChild</directive> +
203 (<directive>AsyncRequestWorkerFactor</directive> *
204 <var>nombre de threads inactifs</var>)
207 <p>En d'autres termes, le nombre maximum de connexions simultanées
210 <p class="indent"><strong>
211 (<directive>AsyncRequestWorkerFactor</directive> + 1) *
212 <directive module="mpm_common">MaxRequestWorkers</directive>
215 <p>La directive <directive
216 module="mpm_common">MaxRequestWorkers</directive> se nommait
217 <directive>MaxClients</directive> avant la version 2.3.13. La valeur
218 ci-dessus montre que cet ancien nom ne correspondait pas à sa
219 signification exacte pour le MPM event.</p>
221 <p>La directive <directive>AsyncRequestWorkerFactor</directive>
222 accepte des valeurs d'argument de type non entier, comme "1.5".</p>
projects / apache / blob