1 <?xml version="1.0" encoding="UTF-8"?>
2 <!DOCTYPE modulesynopsis SYSTEM "../style/modulesynopsis.dtd">
3 <?xml-stylesheet type="text/xsl" href="../style/manual.fr.xsl"?>
4 <!-- English Revision: 1820539 -->
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, comme son nom
35 l'indique, une implémentation asynchrone basée sur les évènements et conçu
36 pour permettre le traitement d'un nombre accru de requêtes
37 simultanées en déléguant certaines tâches
38 aux threads d'écoute, libérant par là-même les
39 threads de travail et leur permettant de traiter les nouvelles requêtes.</p>
41 <p>Pour utiliser le MPM <module>event</module>, ajoutez
42 <code>--with-mpm=event</code> aux arguments du script
43 <program>configure</program> lorsque vous compilez le programme
44 <program>httpd</program>.</p>
48 <seealso><a href="worker.html">Le MPM worker</a></seealso>
50 <section id="event-worker-relationship"><title>Relations avec le MPM Worker</title>
51 <p>Le MPM <module>event</module> s'inspire du MPM <module>worker</module> qui
52 implémente un serveur hybride multi-processus et multi-threads. Un processus de
53 contrôle unique (le parent) est chargé de lancer des processus enfants. Chaque
54 processus enfant crée un nombre de threads serveurs défini via la directive
55 <directive module="mpm_common">ThreadsPerChild</directive>, ainsi qu'un thread
56 d'écoute qui surveille les requêtes entrantes et les distribue aux threads de
57 travail pour traitement au fur et à mesure de leur arrivée.</p>
59 <p>Les directives de configuration à l'exécution sont identiques à celles que
60 propose le MPM <module>worker</module>, avec l'unique addition de la directive
61 <directive>AsyncRequestWorkerFactor</directive>.</p>
65 <section id="how-it-works"><title>Comment tout cela fonctionne</title>
67 <p>Ce module MPM a été conçu à l'origine pour résoudre le "problème keep
68 alive" de HTTP. Lorsqu'un client a effectué une première requête, il peut
69 garder la connexion ouverte et envoyer les requêtes suivante en utilisant le
70 même socket, ce qui diminue considérablement la charge qui aurait été
71 induite par la création de nouvelles connexions TCP. Cependant, le
72 fonctionnement du serveur HTTP Apache impose de réserver un couple processus
73 enfant/thread pour attendre les données en provenance du client, ce qui
74 présente certains inconvénients. Pour résoudre ce problème, le MPM Event
75 utilise un thread d'écoute dédié pour chaque processus associé à un jeu de
76 threads de travail, partageant les files d'attentes spécifiques aux
77 requêtes en mode keep-alive (ou plus simplement en mode "lisible"), à celles
78 en mode écriture des résultats, et à celles en court de fermeture
79 ("closing"). Une boucle d'attente d'évènements déclenchée en fonction du
80 statut de la disponibilité du socket ajuste ces files d'attente et distribue
81 le travail au jeu de threads de travail.
84 <p>Cette nouvelle architecture, en exploitant les sockets non blocants et
85 les fonctionnalités des noyaux modernes mis en valeur par
86 <glossary>APR</glossary> (comme epoll de Linux), n'a plus besoin du
87 <directive module="core">Mutex</directive> <code>mpm-accept</code> pour
88 éviter le problème de "thundering herd".</p>
90 <p>La directive <directive>AsyncRequestWorkerFactor</directive> permet de
91 définir le nombre total de connexions qu'un bloc processus/thread peut
94 <section id="async-connections"><title>Connexions asynchrones</title>
95 <p>Avec les MPM précédents, les connexions asynchrones nécessitaient
96 un thread de travail dédié, mais ce n'est plus le cas avec le MPM Event.
97 La page d'état de <module>mod_status</module> montre de nouvelles
98 colonnes dans la section "Async connections" :</p>
101 <dd>Lors de l'envoi de la réponse au client, il peut arriver que le
102 tampon d'écriture TCP soit plein si la connexion est trop lente. Si
103 cela se produit, une instruction <code>write()</code> vers le socket
104 renvoie en général <code>EWOULDBLOCK</code> ou <code>EAGAIN</code>
105 pour que l'on puisse y écrire à nouveau après un certain temps
106 d'inactivité. Le thread de travail qui utilise le socket doit alors
107 être en mesure de récupérer la tâche en attente et la restituer au
108 thread d'écoute qui, à son tour, la réattribuera au premier thread
109 de travail disponible, lorsqu'un évènement sera généré pour le socket
110 (par exemple, "il est maintenant possible d'écrire dans le socket").
111 Veuillez vous reporter à la section à propos des limitations pour
116 <dd>La gestion des connexions persistantes constitue la principale
117 amélioration par rapport au MPM Worker. Lorsqu'un thread de travail
118 a terminé l'envoi d'une réponse à un client, il peut restituer la
119 gestion du socket au thread d'écoute, qui à son tour va attendre un
120 évènement en provenance du système d'exploitation comme "le socket
121 est lisible". Si une nouvelle requête arrive en provenance du
122 client, le thread d'écoute l'attribuera au premier thread de travail
123 disponible. Inversement, si le délai <directive
124 module="core">KeepAliveTimeout</directive> est atteint, le socket
125 sera fermé par le thread d'écoute. Les threads de travail n'ont
126 donc plus à s'occuper des sockets inactifs et ils peuvent être
127 réutilisés pour traiter d'autres requêtes.</dd>
130 <dd>Parfois, le MPM doit effectuer une fermeture progressive, c'est
131 à dire envoyer au client une erreur survenue précédemment alors que
132 ce dernier est en train de transmettre des données à httpd. Envoyer la réponse et
133 fermer immédiatement la connexion n'est pas une bonne solution car
134 le client (qui est encore en train d'envoyer le reste de la requête)
135 verrait sa connexion réinitialisée et ne pourrait pas lire la
137 La fermeture progressive est limitée dans le temps,
138 mais elle peut tout de même être assez longue, si bien qu'elle est
139 confiée à un thread de travail (y compris les procédures d'arrêt et
140 la fermeture effective du socket). A partir de la version 2.4.28,
141 c'est aussi le cas lorsque des connexions finissent par dépasser
142 leur délai d'attente (le thread d'écoute ne gère jamais les
143 connexions, si ce n'est attendre et dispatcher les évènements
144 qu'elles génèrent).</dd>
147 <p>Ces améliorations sont disponible pour les connexions HTTP ou HTTPS.</p>
149 <p>Les états de connexions ci-dessus sont gérés par le thread d'écoute
150 via des files d'attente dédiées qui, jusqu'à la version 2.4.27, étaient
151 lues toutes les 100ms pour déterminer quelles connexions avaient atteint
152 des limites de durées définies comme <directive
153 module="mpm_common">Timeout</directive> et <directive
154 module="core">KeepAliveTimeout</directive>. C'était une solution simple
155 et efficace mais qui présentait un inconvénient : ces lectures
156 régulières forçaient le thread d'écoute à se réveiller, souvent sans
157 nécessité (alors qu'il était totalement inactif), ce qui consommait des
158 ressources pour rien. A partir de la version 2.4.28, ces files d'attente
159 sont entièrement gérées selon une logique basées sur les évènements, et
160 ne font donc plus l'objet d'une lecture systématique. Les environnements
161 aux ressources limitées, comme les serveurs embarqués, seront les plus
162 grands bénéficiaires de cette amélioration.</p>
166 <section id="graceful-close"><title>Arrêt de processus en douceur et
167 utilisation du scoreboard</title>
168 <p>Ce MPM présentait dans le passé des limitations de montée en
170 provoquaient l'erreur suivante : "<strong>scoreboard is full, not at
171 MaxRequestWorkers</strong>". La directive <directive
172 module="mpm_common">MaxRequestWorkers</directive> permet de limiter le
173 nombre de requêtes pouvant être servies simultanément à un moment donné
174 ainsi que le nombre de processus autorisés (<directive
175 module="mpm_common">MaxRequestWorkers</directive> / <directive
176 module="mpm_common">ThreadsPerChild</directive>), alors que le
177 scoreboard représente l'ensemble des processus en cours d'exécution et
178 l'état de leurs threads de travail. Si le scoreboard est plein
179 (autrement dit si aucun des threads n'est dans un état inactif) et si le
180 nombre de requêtes actives servies est inférieur à <directive
181 module="mpm_common">MaxRequestWorkers</directive>, cela signifie que
182 certains d'entre eux bloquent les nouvelles requêtes qui pourraient être
183 servies et sont en l'occurrence mises en attente (dans la limite de la
184 valeur imposée par la directive <directive
185 module="mpm_common">ListenBacklog</directive>). La plupart du temps, ces
186 threads sont bloqués dans un état d'arrêt en douceur car ils attendent
187 de terminer leur travail sur une connexion TCP pour s'arrêter et ainsi libérer
188 une entrée dans le scoreboard (par exemple dans le cas du traitement des
189 requêtes de longue durée, des clients lents ou des connexions en
190 keep-alive). Voici deux scénarios courants :</p>
192 <li>Pendant un <a href="../stopping.html#graceful">graceful
193 restart</a>. Le processus parent demande à tous ses processus
194 enfants de terminer leur travail et de s'arrêter pendant qu'il
195 recharge la configuration et lance de nouveaux processus. Si les
196 processus existants continuent de s'exécuter pendant un certain
197 temps avant de s'arrêter, le scoreboard sera partiellement occupé
198 jusqu'à ce que les entrées correspondantes soient libérées.
200 <li>Lorsque la charge du serveur diminue suffisamment pour que httpd
201 commence à stopper certains processus (par exemple pour respecter la
202 valeur de la directive <directive
203 module="mpm_common">MaxSpareThreads</directive>). Cette situation
204 est problèmatique car lorsque la charge augmente à nouveau, httpd va
205 essayer de lancer de nouveaux processus. Si cette situation se
206 répète, le nombre de processus peut augmenter sensiblement,
207 aboutissant à un mélange d'anciens processus tentant de s'arrêter et
208 de nouveaux processus tentant d'effectuer un travail quelconque.
211 <p>A partir de la version 2.4.24, mpm-event est plus intelligent et peut
212 traiter les arrêts graceful de manière plus efficace. Voici certaines de
213 ces améliorations :</p>
215 <li>Utilisation de toutes les entrées du scoreboard dans la limite
216 de la valeur définie par <directive
217 module="mpm_common">ServerLimit</directive>. Les directives
218 <directive module="mpm_common">MaxRequestWorkers</directive> et
219 <directive module="mpm_common">ThreadsPerChild</directive>
220 permettent de limiter le nombre de processus actifs, alors que la
221 directive <directive module="mpm_common">ServerLimit</directive>
222 prend aussi en compte les proccessus en arrêt graceful pour
223 permettre l'utilisation d'entrées supplémentaires du scoreboard en
224 cas de besoin. L'idée consiste à utiliser <directive
225 module="mpm_common">ServerLimit</directive> pour indiquer à httpd
226 conbien de processus supplémentaires seront tolérés avant
227 d'atteindre les limites imposées par les ressources du système.
229 <li>Les processus en arrêt graceful doivent fermer leurs connexions
231 <li>Lors d'un arrêt graceful, s'il y a plus de threads de travail en
232 cours d'exécution que de connexions ouvertes pour un processus
233 donné, ces threads sont arrêtés afin de libérer les ressources plus
234 vite (ce qui peut s'avérer nécessaire pour lancer de nouveaux
236 <li>Si le scoreboard est plein, empêche d'arrêter d'autres processus
237 en mode graceful afin de réduire la charge jusqu'à ce que tous les
238 anciens processus soient arrêtés (sinon la situation empirerait lors
239 d'une remontée en charge).</li>
241 <p>Le comportement décrit dans le dernier point est bien visible via
242 <module>mod_status</module> dans la table des connexions avec les deux
243 nouvelles colonnes "Slot" et "Stopping". La première indique le PID et
244 la seconde si le processus est en cours d'arrêt ou non ; l'état
245 supplémentaire "Yes (old gen)" indique un processus encore en exécution
246 après un redémarrage graceful.</p>
249 <section id="limitations"><title>Limitations</title>
250 <p>La gestion améliorée des connexions peut ne pas fonctionner pour
251 certains filtres de connexion qui se sont déclarés eux-mêmes
252 incompatibles avec le MPM Event. Dans ce cas, le MPM Event réadoptera le
253 comportement du MPM <module>worker</module> et réservera un thread de
254 travail par connexion. Notez que tous les modules inclus dans la
255 distribution du serveur httpd sont compatibles avec le MPM Event.</p>
257 <p>Une restriction similaire apparaît lorsqu'une requête utilise un
258 filtre en sortie qui doit pouvoir lire et/ou modifier la totalité du
259 corps de la réponse. Si la connexion avec le client se bloque pendant
260 que le filtre traite les données, et si la quantité de données produites
261 par le filtre est trop importante pour être stockée en mémoire, le
262 thread utilisé pour la requête n'est pas libéré pendant que httpd attend
263 que les données soient transmises au client.<br />
264 Pour illustrer ce cas de figure, nous pouvons envisager les deux
265 situations suivantes : servir une ressource statique (comme un fichier
266 CSS) ou servir un contenu issu d'un programme FCGI/CGI ou d'un serveur
267 mandaté. La première situation est prévisible ; en effet, le MPM Event a
268 une parfaite visibilité sur la fin du contenu, et il peut utiliser les
269 évènements : le thread de travail qui sert la réponse peut envoyer les
270 premiers octets jusqu'à ce que <code>EWOULDBLOCK</code> ou
271 <code>EAGAIN</code> soit renvoyé, et déléguer le reste de la réponse au thread
272 d'écoute. Ce dernier en retour attend un évènement sur le socket, et
273 délègue le reste de la réponse au premier
274 thread de travail disponible. Dans la deuxième situation par contre
275 (FCGI/CGI/contenu mandaté), le MPM n'a pas de visibilité sur la fin de
276 la réponse, et le thread de travail doit terminer sa tâche avant de
277 rendre le contrôle au thread d'écoute. La seule solution consisterait
278 alors à stocker la réponse en mémoire, mais ce ne serait pas l'option la
279 plus sure en matière de stabilité du serveur et d'empreinte mémoire.
284 <section id="background"><title>Matériel d'arrière-plan</title>
285 <p>Le modèle event a été rendu possible par l'introduction de nouvelles
286 APIs dans les systèmes d'exploitation supportés :</p>
288 <li>epoll (Linux) </li>
289 <li>kqueue (BSD) </li>
290 <li>event ports (Solaris) </li>
292 <p>Avant que ces APIs soient mises à disposition, les APIs
293 traditionnelles <code>select</code> et <code>poll</code> devaient être
294 utilisées. Ces APIs deviennent lentes si on les utilise pour gérer de
295 nombreuses connexions ou si le jeu de connexions possède un taux de
296 renouvellement élevé. Les nouvelles APIs permettent de gérer beaucoup
297 plus de connexions et leur performances sont meilleures lorsque le jeu
298 de connexions à gérer change fréquemment. Ces APIs ont donc rendu
299 possible l'écriture le MPM Event qui est mieux adapté à la situation
300 HTTP typique où de nombreuses connexions sont inactives.</p>
302 <p>Le MPM Event suppose que l'implémentation de <code>apr_pollset</code>
303 sous-jacente est raisonnablement sure avec l'utilisation des threads
304 (threadsafe). Ceci évite au MPM de devoir effectuer trop verrouillages
305 de haut niveau, ou d'avoir à réveiller le thread d'écoute pour lui
306 envoyer un socket keep-alive. Ceci n'est possible qu'avec KQueue et
313 <section id="requirements"><title>Prérequis</title>
314 <p>Ce MPM dépend des opérations atomiques compare-and-swap
315 d'<glossary>APR</glossary> pour la synchronisation des threads. Si
316 vous compilez pour une plate-forme x86 et n'avez pas besoin du
317 support 386, ou si vous compilez pour une plate-forme SPARC et
318 n'avez pas besoin du support pre-UltraSPARC, ajoutez
319 <code>--enable-nonportable-atomics=yes</code> aux arguments du
320 script <program>configure</program>. Ceci permettra à APR
321 d'implémenter les opérations atomiques en utilisant des instructions
322 performantes indisponibles avec les processeurs plus
325 <p>Ce MPM ne fonctionne pas de manière optimale sur les
326 plates-formes plus anciennes qui ne gèrent pas correctement les
327 threads, mais ce problème est sans objet du fait du prérequis
328 concernant EPoll ou KQueue.</p>
332 <li>Pour utiliser ce MPM sous FreeBSD, la version 5.3 ou
333 supérieure de ce système est recommandée. Il est cependant
334 possible d'exécuter ce MPM sous FreeBSD 5.2.1 si vous utilisez
335 <code>libkse</code> (voir <code>man libmap.conf</code>).</li>
337 <li>Pour NetBSD, il est recommander d'utiliser la version 2.0 ou
340 <li>Pour Linux, un noyau 2.6 est recommandé. Il faut aussi
341 s'assurer que votre version de <code>glibc</code> a été compilée
342 avec le support pour EPoll.</li>
347 <directivesynopsis location="mpm_common"><name>CoreDumpDirectory</name>
349 <directivesynopsis location="mpm_common"><name>EnableExceptionHook</name>
351 <directivesynopsis location="mod_unixd"><name>Group</name>
353 <directivesynopsis location="mpm_common"><name>Listen</name>
355 <directivesynopsis location="mpm_common"><name>ListenBacklog</name>
357 <directivesynopsis location="mpm_common"><name>SendBufferSize</name>
359 <directivesynopsis location="mpm_common"><name>MaxRequestWorkers</name>
361 <directivesynopsis location="mpm_common"><name>MaxMemFree</name>
363 <directivesynopsis location="mpm_common"><name>MaxConnectionsPerChild</name>
365 <directivesynopsis location="mpm_common"><name>MaxSpareThreads</name>
367 <directivesynopsis location="mpm_common"><name>MinSpareThreads</name>
369 <directivesynopsis location="mpm_common"><name>PidFile</name>
371 <directivesynopsis location="mpm_common"><name>ScoreBoardFile</name>
373 <directivesynopsis location="mpm_common"><name>ServerLimit</name>
375 <directivesynopsis location="mpm_common"><name>StartServers</name>
377 <directivesynopsis location="mpm_common"><name>ThreadLimit</name>
379 <directivesynopsis location="mpm_common"><name>ThreadsPerChild</name>
381 <directivesynopsis location="mpm_common"><name>ThreadStackSize</name>
383 <directivesynopsis location="mod_unixd"><name>User</name>
387 <name>AsyncRequestWorkerFactor</name>
388 <description>Limite le nombre de connexions simultanées par thread</description>
389 <syntax>AsyncRequestWorkerFactor <var>facteur</var></syntax>
391 <contextlist><context>server config</context> </contextlist>
392 <compatibility>Disponible depuis la version 2.3.13</compatibility>
395 <p>Le MPM event gère certaines connexions de manière asynchrone ;
396 dans ce cas, les threads traitant la requête sont alloués selon les
397 besoins et pour de courtes périodes. Dans les autres cas, un
398 thread est réservé par
399 connexion. Ceci peut conduire à des situations où tous les threads
400 sont saturés et où aucun thread n'est capable d'effectuer de
401 nouvelles tâches pour les connexions asynchrones établies.</p>
403 <p>Pour minimiser les effets de ce problème, le MPM event utilise
406 <li>il limite le nombre de connexions
407 simultanées par thread en fonction du nombre de processus
409 <li>si tous les processus sont occupés, il ferme des connexions
410 permanentes, même si la limite de durée de la connexion n'a
411 pas été atteinte. Ceci autorise les clients
412 concernés à se reconnecter à un autre processus
413 possèdant encore des threads disponibles.</li>
416 <p>Cette directive permet de personnaliser finement la limite du
417 nombre de connexions par thread. Un <strong>processus</strong> n'acceptera de
418 nouvelles connexions que si le nombre actuel de connexions (sans
419 compter les connexions à l'état "closing") est
422 <p class="indent"><strong>
423 <directive module="mpm_common">ThreadsPerChild</directive> +
424 (<directive>AsyncRequestWorkerFactor</directive> *
425 <var>nombre de threads inactifs</var>)
428 <p>Il est possible d'effectuer une estimation du nombre maximum de
429 connexions simultanées pour tous les processus et pour un nombre donné moyen
430 de threads de travail inactifs comme suit :
434 <p class="indent"><strong>
435 (<directive module="mpm_common">ThreadsPerChild</directive> +
436 (<directive>AsyncRequestWorkerFactor</directive> *
437 <var>number of idle workers</var>)) *
438 <directive module="mpm_common">ServerLimit</directive>
441 <note><title>Exemple</title>
442 <highlight language="config">
446 AsyncRequestWorkerFactor = 2
447 MaxRequestWorkers = 40
449 idle_workers = 4 (moyenne pour tous les processus pour faire simple)
451 max_connections = (ThreadsPerChild + (AsyncRequestWorkerFactor * idle_workers)) * ServerLimit
452 = (10 + (2 * 4)) * 4 = 72
457 <p>Lorsque tous les threads de travail sont inactifs, le nombre maximum
458 absolu de connexions simultanées peut être calculé de manière plus simple :</p>
460 <p class="indent"><strong>
461 (<directive>AsyncRequestWorkerFactor</directive> + 1) *
462 <directive module="mpm_common">MaxRequestWorkers</directive>
465 <note><title>Exemple</title>
466 <highlight language="config">
470 MaxRequestWorkers = 40
471 AsyncRequestWorkerFactor = 2
475 <p>Si tous les threads de tous les processus sont inactifs, alors :</p>
477 <highlight language="config">idle_workers = 10</highlight>
479 <p>Nous pouvons calculer le nombre maximum absolu de connexions simultanées
480 de deux manières :</p>
482 <highlight language="config">
484 max_connections = (ThreadsPerChild + (AsyncRequestWorkerFactor * idle_workers)) * ServerLimit
485 = (10 + (2 * 10)) * 4 = 120
487 max_connections = (AsyncRequestWorkerFactor + 1) * MaxRequestWorkers
493 <p>Le réglage de la directive
494 <directive>AsyncRequestWorkerFactor</directive> nécessite de connaître le
495 trafic géré par httpd pour chaque style d'utilisation spécifique ; si vous
496 modifiez la valeur par défaut, vous devrez par conséquent effectuer des
497 tests approfondis en vous appuyant étroitement sur les données fournies par
498 <module>mod_status</module>.</p>
500 <p>La directive <directive
501 module="mpm_common">MaxRequestWorkers</directive> se nommait
502 <directive>MaxClients</directive> avant la version 2.3.13. La valeur
503 ci-dessus montre que cet ancien nom ne correspondait pas à sa
504 signification exacte pour le MPM event.</p>
506 <p>La directive <directive>AsyncRequestWorkerFactor</directive>
507 accepte des valeurs d'argument de type non entier, comme "1.5".</p>