1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
|
<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" lang="fr" xml:lang="fr"><head>
<meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type" />
<!--
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
This file is generated from xml source: DO NOT EDIT
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
-->
<title>event - Serveur HTTP Apache Version 2.5</title>
<link href="../style/css/manual.css" rel="stylesheet" media="all" type="text/css" title="Main stylesheet" />
<link href="../style/css/manual-loose-100pc.css" rel="alternate stylesheet" media="all" type="text/css" title="No Sidebar - Default font size" />
<link href="../style/css/manual-print.css" rel="stylesheet" media="print" type="text/css" /><link rel="stylesheet" type="text/css" href="../style/css/prettify.css" />
<script src="../style/scripts/prettify.min.js" type="text/javascript">
</script>
<link href="../images/favicon.ico" rel="shortcut icon" /></head>
<body>
<div id="page-header">
<p class="menu"><a href="../mod/">Modules</a> | <a href="../mod/quickreference.html">Directives</a> | <a href="http://wiki.apache.org/httpd/FAQ">FAQ</a> | <a href="../glossary.html">Glossaire</a> | <a href="../sitemap.html">Plan du site</a></p>
<p class="apache">Serveur HTTP Apache Version 2.5</p>
<img alt="" src="../images/feather.png" /></div>
<div class="up"><a href="./"><img title="<-" alt="<-" src="../images/left.gif" /></a></div>
<div id="path">
<a href="http://www.apache.org/">Apache</a> > <a href="http://httpd.apache.org/">Serveur HTTP</a> > <a href="http://httpd.apache.org/docs/">Documentation</a> > <a href="../">Version 2.5</a> > <a href="./">Modules</a></div>
<div id="page-content">
<div id="preamble"><h1>Apache MPM event</h1>
<div class="toplang">
<p><span>Langues Disponibles: </span><a href="../en/mod/event.html" hreflang="en" rel="alternate" title="English"> en </a> |
<a href="../es/mod/event.html" hreflang="es" rel="alternate" title="Espa�ol"> es </a> |
<a href="../fr/mod/event.html" title="Fran�ais"> fr </a></p>
</div>
<table class="module"><tr><th><a href="module-dict.html#Description">Description:</a></th><td>Une variante du MPM <code class="module"><a href="../mod/worker.html">worker</a></code> con�ue pour ne
mobiliser des threads que pour les connexions en cours de traitement</td></tr>
<tr><th><a href="module-dict.html#Status">Statut:</a></th><td>MPM</td></tr>
<tr><th><a href="module-dict.html#ModuleIdentifier">Identificateur�de�Module:</a></th><td>mpm_event_module</td></tr>
<tr><th><a href="module-dict.html#SourceFile">Fichier�Source:</a></th><td>event.c</td></tr></table>
<h3>Sommaire</h3>
<p>Le module multi-processus (MPM) <code class="module"><a href="../mod/event.html">event</a></code> est, comme son nom
l'indique, une impl�mentation asynchrone bas�e sur les �v�nements et con�u
pour permettre le traitement d'un nombre accru de requ�tes
simultan�es en d�l�guant certaines t�ches
aux threads d'�coute, lib�rant par l�-m�me les
threads de travail et leur permettant de traiter les nouvelles requ�tes.</p>
<p>Pour utiliser le MPM <code class="module"><a href="../mod/event.html">event</a></code>, ajoutez
<code>--with-mpm=event</code> aux arguments du script
<code class="program"><a href="../programs/configure.html">configure</a></code> lorsque vous compilez le programme
<code class="program"><a href="../programs/httpd.html">httpd</a></code>.</p>
</div>
<div id="quickview"><h3>Sujets</h3>
<ul id="topics">
<li><img alt="" src="../images/down.gif" /> <a href="#event-worker-relationship">Relations avec le MPM Worker</a></li>
<li><img alt="" src="../images/down.gif" /> <a href="#how-it-works">Comment tout cela fonctionne</a></li>
<li><img alt="" src="../images/down.gif" /> <a href="#requirements">Pr�requis</a></li>
</ul><h3 class="directives">Directives</h3>
<ul id="toc">
<li><img alt="" src="../images/down.gif" /> <a href="#asyncrequestworkerfactor">AsyncRequestWorkerFactor</a></li>
<li><img alt="" src="../images/right.gif" /> <a href="mpm_common.html#coredumpdirectory">CoreDumpDirectory</a></li>
<li><img alt="" src="../images/right.gif" /> <a href="mpm_common.html#enableexceptionhook">EnableExceptionHook</a></li>
<li><img alt="" src="../images/right.gif" /> <a href="mod_unixd.html#group">Group</a></li>
<li><img alt="" src="../images/right.gif" /> <a href="mpm_common.html#listen">Listen</a></li>
<li><img alt="" src="../images/right.gif" /> <a href="mpm_common.html#listenbacklog">ListenBacklog</a></li>
<li><img alt="" src="../images/right.gif" /> <a href="mpm_common.html#maxconnectionsperchild">MaxConnectionsPerChild</a></li>
<li><img alt="" src="../images/right.gif" /> <a href="mpm_common.html#maxmemfree">MaxMemFree</a></li>
<li><img alt="" src="../images/right.gif" /> <a href="mpm_common.html#maxrequestworkers">MaxRequestWorkers</a></li>
<li><img alt="" src="../images/right.gif" /> <a href="mpm_common.html#maxsparethreads">MaxSpareThreads</a></li>
<li><img alt="" src="../images/right.gif" /> <a href="mpm_common.html#minsparethreads">MinSpareThreads</a></li>
<li><img alt="" src="../images/right.gif" /> <a href="mpm_common.html#pidfile">PidFile</a></li>
<li><img alt="" src="../images/right.gif" /> <a href="mpm_common.html#scoreboardfile">ScoreBoardFile</a></li>
<li><img alt="" src="../images/right.gif" /> <a href="mpm_common.html#sendbuffersize">SendBufferSize</a></li>
<li><img alt="" src="../images/right.gif" /> <a href="mpm_common.html#serverlimit">ServerLimit</a></li>
<li><img alt="" src="../images/right.gif" /> <a href="mpm_common.html#startservers">StartServers</a></li>
<li><img alt="" src="../images/right.gif" /> <a href="mpm_common.html#threadlimit">ThreadLimit</a></li>
<li><img alt="" src="../images/right.gif" /> <a href="mpm_common.html#threadsperchild">ThreadsPerChild</a></li>
<li><img alt="" src="../images/right.gif" /> <a href="mpm_common.html#threadstacksize">ThreadStackSize</a></li>
<li><img alt="" src="../images/right.gif" /> <a href="mod_unixd.html#user">User</a></li>
</ul>
<h3>Traitement des bugs</h3><ul class="seealso"><li><a href="https://www.apache.org/dist/httpd/CHANGES_2.4">Journal des modifications de httpd</a></li><li><a href="https://bz.apache.org/bugzilla/buglist.cgi?bug_status=__open__&list_id=144532&product=Apache%20httpd-2&query_format=specific&order=changeddate%20DESC%2Cpriority%2Cbug_severity&component=mpm_event">Probl�mes connus</a></li><li><a href="https://bz.apache.org/bugzilla/enter_bug.cgi?product=Apache%20httpd-2&component=mpm_event">Signaler un bug</a></li></ul><h3>Voir aussi</h3>
<ul class="seealso">
<li><a href="worker.html">Le MPM worker</a></li>
<li><a href="#comments_section">Commentaires</a></li></ul></div>
<div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
<div class="section">
<h2><a name="event-worker-relationship" id="event-worker-relationship">Relations avec le MPM Worker</a><a title="Lien permanent" href="#event-worker-relationship" class="permalink">¶</a></h2>
<p>Le MPM <code class="module"><a href="../mod/event.html">event</a></code> s'inspire du MPM <code class="module"><a href="../mod/worker.html">worker</a></code> qui
impl�mente un serveur hybride multi-processus et multi-threads. Un processus de
contr�le unique (le parent) est charg� de lancer des processus enfants. Chaque
processus enfant cr�e un nombre de threads serveurs d�fini via la directive
<code class="directive"><a href="../mod/mpm_common.html#threadsperchild">ThreadsPerChild</a></code>, ainsi qu'un thread
d'�coute qui surveille les requ�tes entrantes et les distribue aux threads de
travail pour traitement au fur et � mesure de leur arriv�e.</p>
<p>Les directives de configuration � l'ex�cution sont identiques � celles que
propose le MPM <code class="module"><a href="../mod/worker.html">worker</a></code>, avec l'unique addition de la directive
<code class="directive">AsyncRequestWorkerFactor</code>.</p>
</div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
<div class="section">
<h2><a name="how-it-works" id="how-it-works">Comment tout cela fonctionne</a><a title="Lien permanent" href="#how-it-works" class="permalink">¶</a></h2>
<p>Ce module MPM a �t� con�u � l'origine pour r�soudre le "probl�me keep
alive" de HTTP. Lorsqu'un client a effectu� une premi�re requ�te, il peut
garder la connexion ouverte et envoyer les requ�tes suivante en utilisant le
m�me socket, ce qui diminue consid�rablement la charge qui aurait �t�
induite par la cr�ation de nouvelles connexions TCP. Cependant, le
fonctionnement du serveur HTTP Apache impose de r�server un couple processus
enfant/thread pour attendre les donn�es en provenance du client, ce qui
pr�sente certains inconv�nients. Pour r�soudre ce probl�me, le MPM Event
utilise un thread d'�coute d�di� pour chaque processus associ� � un jeu de
threads de travail, partageant les files d'attentes sp�cifiques aux
requ�tes en mode keep-alive (ou plus simplement en mode "lisible"), � celles
en mode �criture des r�sultats, et � celles en court de fermeture
("closing"). Une boucle d'attente d'�v�nements d�clench�e en fonction du
statut de la disponibilit� du socket ajuste ces files d'attente et distribue
le travail au jeu de threads de travail.
</p>
<p>Cette nouvelle architecture, en exploitant les sockets non blocants et
les fonctionnalit�s des noyaux modernes mis en valeur par
<a class="glossarylink" href="../glossary.html#apr" title="voir glossaire">APR</a> (comme epoll de Linux), n'a plus besoin du
<code class="directive"><a href="../mod/core.html#mutex">Mutex</a></code> <code>mpm-accept</code> pour
�viter le probl�me de "thundering herd".</p>
<p>La directive <code class="directive">AsyncRequestWorkerFactor</code> permet de
d�finir le nombre total de connexions qu'un bloc processus/thread peut
g�rer.</p>
<h3><a name="async-connections" id="async-connections">Connexions asynchrones</a></h3>
<p>Avec les MPM pr�c�dents, les connexions asynchrones n�cessitaient
un thread de travail d�di�, mais ce n'est plus le cas avec le MPM Event.
La page d'�tat de <code class="module"><a href="../mod/mod_status.html">mod_status</a></code> montre de nouvelles
colonnes dans la section "Async connections" :</p>
<dl>
<dt>Writing</dt>
<dd>Lors de l'envoi de la r�ponse au client, il peut arriver que le
tampon d'�criture TCP soit plein si la connexion est trop lente. Si
cela se produit, une instruction <code>write()</code> vers le socket
renvoie en g�n�ral <code>EWOULDBLOCK</code> ou <code>EAGAIN</code>
pour que l'on puisse y �crire � nouveau apr�s un certain temps
d'inactivit�. Le thread de travail qui utilise le socket doit alors
�tre en mesure de r�cup�rer la t�che en attente et la restituer au
thread d'�coute qui, � son tour, la r�attribuera au premier thread
de travail disponible, lorsqu'un �v�nement sera g�n�r� pour le socket
(par exemple, "il est maintenant possible d'�crire dans le socket").
Veuillez vous reporter � la section � propos des limitations pour
plus de d�tails.
</dd>
<dt>Keep-alive</dt>
<dd>La gestion des connexions persistantes constitue la principale
am�lioration par rapport au MPM Worker. Lorsqu'un thread de travail
a termin� l'envoi d'une r�ponse � un client, il peut restituer la
gestion du socket au thread d'�coute, qui � son tour va attendre un
�v�nement en provenance du syst�me d'exploitation comme "le socket
est lisible". Si une nouvelle requ�te arrive en provenance du
client, le thread d'�coute l'attribuera au premier thread de travail
disponible. Inversement, si le d�lai <code class="directive"><a href="../mod/core.html#keepalivetimeout">KeepAliveTimeout</a></code> est atteint, le socket
sera ferm� par le thread d'�coute. Les threads de travail n'ont
donc plus � s'occuper des sockets inactifs et ils peuvent �tre
r�utilis�s pour traiter d'autres requ�tes.</dd>
<dt>Closing</dt>
<dd>Parfois, le MPM doit effectuer une fermeture progressive, c'est
� dire envoyer au client une erreur survenue pr�c�demment alors que
ce dernier est en train de transmettre des donn�es � httpd. Envoyer la r�ponse et
fermer imm�diatement la connexion n'est pas une bonne solution car
le client (qui est encore en train d'envoyer le reste de la requ�te)
verrait sa connexion r�initialis�e et ne pourrait pas lire la
r�ponse de httpd.
La fermeture progressive est limit�e dans le temps,
mais elle peut tout de m�me �tre assez longue, si bien qu'elle est
confi�e � un thread de travail (y compris les proc�dures d'arr�t et
la fermeture effective du socket). A partir de la version 2.4.28,
c'est aussi le cas lorsque des connexions finissent par d�passer
leur d�lai d'attente (le thread d'�coute ne g�re jamais les
connexions, si ce n'est attendre et dispatcher les �v�nements
qu'elles g�n�rent).</dd>
</dl>
<p>Ces am�liorations sont disponible pour les connexions HTTP ou HTTPS.</p>
<p>Les �tats de connexions ci-dessus sont g�r�s par le thread d'�coute
via des files d'attente d�di�es qui, jusqu'� la version 2.4.27, �taient
lues toutes les 100ms pour d�terminer quelles connexions avaient atteint
des limites de dur�es d�finies comme <code class="directive"><a href="../mod/mpm_common.html#timeout">Timeout</a></code> et <code class="directive"><a href="../mod/core.html#keepalivetimeout">KeepAliveTimeout</a></code>. C'�tait une solution simple
et efficace mais qui pr�sentait un inconv�nient : ces lectures
r�guli�res for�aient le thread d'�coute � se r�veiller, souvent sans
n�cessit� (alors qu'il �tait totalement inactif), ce qui consommait des
ressources pour rien. A partir de la version 2.4.28, ces files d'attente
sont enti�rement g�r�es selon une logique bas�es sur les �v�nements, et
ne font donc plus l'objet d'une lecture syst�matique. Les environnements
aux ressources limit�es, comme les serveurs embarqu�s, seront les plus
grands b�n�ficiaires de cette am�lioration.</p>
<h3><a name="graceful-close" id="graceful-close">Arr�t de processus en douceur et
utilisation du scoreboard</a></h3>
<p>Ce MPM pr�sentait dans le pass� des limitations de mont�e en
puissance qui
provoquaient l'erreur suivante : "<strong>scoreboard is full, not at
MaxRequestWorkers</strong>". La directive <code class="directive"><a href="../mod/mpm_common.html#maxrequestworkers">MaxRequestWorkers</a></code> permet de limiter le
nombre de requ�tes pouvant �tre servies simultan�ment � un moment donn�
ainsi que le nombre de processus autoris�s (<code class="directive"><a href="../mod/mpm_common.html#maxrequestworkers">MaxRequestWorkers</a></code> / <code class="directive"><a href="../mod/mpm_common.html#threadsperchild">ThreadsPerChild</a></code>), alors que le
scoreboard repr�sente l'ensemble des processus en cours d'ex�cution et
l'�tat de leurs threads de travail. Si le scoreboard est plein
(autrement dit si aucun des threads n'est dans un �tat inactif) et si le
nombre de requ�tes actives servies est inf�rieur � <code class="directive"><a href="../mod/mpm_common.html#maxrequestworkers">MaxRequestWorkers</a></code>, cela signifie que
certains d'entre eux bloquent les nouvelles requ�tes qui pourraient �tre
servies et sont en l'occurrence mises en attente (dans la limite de la
valeur impos�e par la directive <code class="directive"><a href="../mod/mpm_common.html#listenbacklog">ListenBacklog</a></code>). La plupart du temps, ces
threads sont bloqu�s dans un �tat d'arr�t en douceur car ils attendent
de terminer leur travail sur une connexion TCP pour s'arr�ter et ainsi lib�rer
une entr�e dans le scoreboard (par exemple dans le cas du traitement des
requ�tes de longue dur�e, des clients lents ou des connexions en
keep-alive). Voici deux sc�narios courants :</p>
<ul>
<li>Pendant un <a href="../stopping.html#graceful">graceful
restart</a>. Le processus parent demande � tous ses processus
enfants de terminer leur travail et de s'arr�ter pendant qu'il
recharge la configuration et lance de nouveaux processus. Si les
processus existants continuent de s'ex�cuter pendant un certain
temps avant de s'arr�ter, le scoreboard sera partiellement occup�
jusqu'� ce que les entr�es correspondantes soient lib�r�es.
</li>
<li>Lorsque la charge du serveur diminue suffisamment pour que httpd
commence � stopper certains processus (par exemple pour respecter la
valeur de la directive <code class="directive"><a href="../mod/mpm_common.html#maxsparethreads">MaxSpareThreads</a></code>). Cette situation
est probl�matique car lorsque la charge augmente � nouveau, httpd va
essayer de lancer de nouveaux processus. Si cette situation se
r�p�te, le nombre de processus peut augmenter sensiblement,
aboutissant � un m�lange d'anciens processus tentant de s'arr�ter et
de nouveaux processus tentant d'effectuer un travail quelconque.
</li>
</ul>
<p>A partir de la version 2.4.24, mpm-event est plus intelligent et peut
traiter les arr�ts graceful de mani�re plus efficace. Voici certaines de
ces am�liorations :</p>
<ul>
<li>Utilisation de toutes les entr�es du scoreboard dans la limite
de la valeur d�finie par <code class="directive"><a href="../mod/mpm_common.html#serverlimit">ServerLimit</a></code>. Les directives
<code class="directive"><a href="../mod/mpm_common.html#maxrequestworkers">MaxRequestWorkers</a></code> et
<code class="directive"><a href="../mod/mpm_common.html#threadsperchild">ThreadsPerChild</a></code>
permettent de limiter le nombre de processus actifs, alors que la
directive <code class="directive"><a href="../mod/mpm_common.html#serverlimit">ServerLimit</a></code>
prend aussi en compte les proccessus en arr�t graceful pour
permettre l'utilisation d'entr�es suppl�mentaires du scoreboard en
cas de besoin. L'id�e consiste � utiliser <code class="directive"><a href="../mod/mpm_common.html#serverlimit">ServerLimit</a></code> pour indiquer � httpd
conbien de processus suppl�mentaires seront tol�r�s avant
d'atteindre les limites impos�es par les ressources du syst�me.
</li>
<li>Les processus en arr�t graceful doivent fermer leurs connexions
en keep-alive.</li>
<li>Lors d'un arr�t graceful, s'il y a plus de threads de travail en
cours d'ex�cution que de connexions ouvertes pour un processus
donn�, ces threads sont arr�t�s afin de lib�rer les ressources plus
vite (ce qui peut s'av�rer n�cessaire pour lancer de nouveaux
processus).</li>
<li>Si le scoreboard est plein, emp�che d'arr�ter d'autres processus
en mode graceful afin de r�duire la charge jusqu'� ce que tous les
anciens processus soient arr�t�s (sinon la situation empirerait lors
d'une remont�e en charge).</li>
</ul>
<p>Le comportement d�crit dans le dernier point est bien visible via
<code class="module"><a href="../mod/mod_status.html">mod_status</a></code> dans la table des connexions avec les deux
nouvelles colonnes "Slot" et "Stopping". La premi�re indique le PID et
la seconde si le processus est en cours d'arr�t ou non ; l'�tat
suppl�mentaire "Yes (old gen)" indique un processus encore en ex�cution
apr�s un red�marrage graceful.</p>
<h3><a name="limitations" id="limitations">Limitations</a></h3>
<p>La gestion am�lior�e des connexions peut ne pas fonctionner pour
certains filtres de connexion qui se sont d�clar�s eux-m�mes
incompatibles avec le MPM Event. Dans ce cas, le MPM Event r�adoptera le
comportement du MPM <code class="module"><a href="../mod/worker.html">worker</a></code> et r�servera un thread de
travail par connexion. Notez que tous les modules inclus dans la
distribution du serveur httpd sont compatibles avec le MPM Event.</p>
<p>Une restriction similaire appara�t lorsqu'une requ�te utilise un
filtre en sortie qui doit pouvoir lire et/ou modifier la totalit� du
corps de la r�ponse. Si la connexion avec le client se bloque pendant
que le filtre traite les donn�es, et si la quantit� de donn�es produites
par le filtre est trop importante pour �tre stock�e en m�moire, le
thread utilis� pour la requ�te n'est pas lib�r� pendant que httpd attend
que les donn�es soient transmises au client.<br />
Pour illustrer ce cas de figure, nous pouvons envisager les deux
situations suivantes : servir une ressource statique (comme un fichier
CSS) ou servir un contenu issu d'un programme FCGI/CGI ou d'un serveur
mandat�. La premi�re situation est pr�visible ; en effet, le MPM Event a
une parfaite visibilit� sur la fin du contenu, et il peut utiliser les
�v�nements : le thread de travail qui sert la r�ponse peut envoyer les
premiers octets jusqu'� ce que <code>EWOULDBLOCK</code> ou
<code>EAGAIN</code> soit renvoy�, et d�l�guer le reste de la r�ponse au thread
d'�coute. Ce dernier en retour attend un �v�nement sur le socket, et
d�l�gue le reste de la r�ponse au premier
thread de travail disponible. Dans la deuxi�me situation par contre
(FCGI/CGI/contenu mandat�), le MPM n'a pas de visibilit� sur la fin de
la r�ponse, et le thread de travail doit terminer sa t�che avant de
rendre le contr�le au thread d'�coute. La seule solution consisterait
alors � stocker la r�ponse en m�moire, mais ce ne serait pas l'option la
plus sure en mati�re de stabilit� du serveur et d'empreinte m�moire.
</p>
<h3><a name="background" id="background">Mat�riel d'arri�re-plan</a></h3>
<p>Le mod�le event a �t� rendu possible par l'introduction de nouvelles
APIs dans les syst�mes d'exploitation support�s :</p>
<ul>
<li>epoll (Linux) </li>
<li>kqueue (BSD) </li>
<li>event ports (Solaris) </li>
</ul>
<p>Avant que ces APIs soient mises � disposition, les APIs
traditionnelles <code>select</code> et <code>poll</code> devaient �tre
utilis�es. Ces APIs deviennent lentes si on les utilise pour g�rer de
nombreuses connexions ou si le jeu de connexions poss�de un taux de
renouvellement �lev�. Les nouvelles APIs permettent de g�rer beaucoup
plus de connexions et leur performances sont meilleures lorsque le jeu
de connexions � g�rer change fr�quemment. Ces APIs ont donc rendu
possible l'�criture le MPM Event qui est mieux adapt� � la situation
HTTP typique o� de nombreuses connexions sont inactives.</p>
<p>Le MPM Event suppose que l'impl�mentation de <code>apr_pollset</code>
sous-jacente est raisonnablement sure avec l'utilisation des threads
(threadsafe). Ceci �vite au MPM de devoir effectuer trop verrouillages
de haut niveau, ou d'avoir � r�veiller le thread d'�coute pour lui
envoyer un socket keep-alive. Ceci n'est possible qu'avec KQueue et
EPoll.</p>
</div><div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
<div class="section">
<h2><a name="requirements" id="requirements">Pr�requis</a><a title="Lien permanent" href="#requirements" class="permalink">¶</a></h2>
<p>Ce MPM d�pend des op�rations atomiques compare-and-swap
d'<a class="glossarylink" href="../glossary.html#apr" title="voir glossaire">APR</a> 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
<code>--enable-nonportable-atomics=yes</code> aux arguments du
script <code class="program"><a href="../programs/configure.html">configure</a></code>. Ceci permettra � APR
d'impl�menter les op�rations atomiques en utilisant des instructions
performantes indisponibles avec les processeurs plus
anciens.</p>
<p>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.</p>
<ul>
<li>Pour utiliser ce MPM sous FreeBSD, la version 5.3 ou
sup�rieure de ce syst�me est recommand�e. Il est cependant
possible d'ex�cuter ce MPM sous FreeBSD 5.2.1 si vous utilisez
<code>libkse</code> (voir <code>man libmap.conf</code>).</li>
<li>Pour NetBSD, il est recommander d'utiliser la version 2.0 ou
sup�rieure.</li>
<li>Pour Linux, un noyau 2.6 est recommand�. Il faut aussi
s'assurer que votre version de <code>glibc</code> a �t� compil�e
avec le support pour EPoll.</li>
</ul>
</div>
<div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif" /></a></div>
<div class="directive-section"><h2><a name="asyncrequestworkerfactor" id="asyncrequestworkerfactor">Directive</a> <a name="AsyncRequestWorkerFactor" id="AsyncRequestWorkerFactor">AsyncRequestWorkerFactor</a><a title="Lien permanent" href="#asyncrequestworkerfactor" class="permalink">¶</a></h2>
<table class="directive">
<tr><th><a href="directive-dict.html#Description">Description:</a></th><td>Limite le nombre de connexions simultan�es par thread</td></tr>
<tr><th><a href="directive-dict.html#Syntax">Syntaxe:</a></th><td><code>AsyncRequestWorkerFactor <var>facteur</var></code></td></tr>
<tr><th><a href="directive-dict.html#Default">D�faut:</a></th><td><code>2</code></td></tr>
<tr><th><a href="directive-dict.html#Context">Contexte:</a></th><td>configuration globale</td></tr>
<tr><th><a href="directive-dict.html#Status">Statut:</a></th><td>MPM</td></tr>
<tr><th><a href="directive-dict.html#Module">Module:</a></th><td>event</td></tr>
<tr><th><a href="directive-dict.html#Compatibility">Compatibilit�:</a></th><td>Disponible depuis la version 2.3.13</td></tr>
</table>
<p>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.</p>
<p>Pour minimiser les effets de ce probl�me, le MPM event utilise
deux m�thodes :</p>
<ul>
<li>il limite le nombre de connexions
simultan�es par thread en fonction du nombre de processus
inactifs;</li>
<li>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.</li>
</ul>
<p>Cette directive permet de personnaliser finement la limite du
nombre de connexions par thread. Un <strong>processus</strong> n'acceptera de
nouvelles connexions que si le nombre actuel de connexions (sans
compter les connexions � l'�tat "closing") est
inf�rieur � :</p>
<p class="indent"><strong>
<code class="directive"><a href="../mod/mpm_common.html#threadsperchild">ThreadsPerChild</a></code> +
(<code class="directive">AsyncRequestWorkerFactor</code> *
<var>nombre de threads inactifs</var>)
</strong></p>
<p>Il est possible d'effectuer une estimation du nombre maximum de
connexions simultan�es pour tous les processus et pour un nombre donn� moyen
de threads de travail inactifs comme suit :
</p>
<p class="indent"><strong>
(<code class="directive"><a href="../mod/mpm_common.html#threadsperchild">ThreadsPerChild</a></code> +
(<code class="directive">AsyncRequestWorkerFactor</code> *
<var>number of idle workers</var>)) *
<code class="directive"><a href="../mod/mpm_common.html#serverlimit">ServerLimit</a></code>
</strong></p>
<div class="note"><h3>Exemple</h3>
<pre class="prettyprint lang-config">ThreadsPerChild = 10
ServerLimit = 4
AsyncRequestWorkerFactor = 2
MaxRequestWorkers = 40
idle_workers = 4 (moyenne pour tous les processus pour faire simple)
max_connections = (ThreadsPerChild + (AsyncRequestWorkerFactor * idle_workers)) * ServerLimit
= (10 + (2 * 4)) * 4 = 72</pre>
</div>
<p>Lorsque tous les threads de travail sont inactifs, le nombre maximum
absolu de connexions simultan�es peut �tre calcul� de mani�re plus simple :</p>
<p class="indent"><strong>
(<code class="directive">AsyncRequestWorkerFactor</code> + 1) *
<code class="directive"><a href="../mod/mpm_common.html#maxrequestworkers">MaxRequestWorkers</a></code>
</strong></p>
<div class="note"><h3>Exemple</h3>
<pre class="prettyprint lang-config">ThreadsPerChild = 10
ServerLimit = 4
MaxRequestWorkers = 40
AsyncRequestWorkerFactor = 2</pre>
<p>Si tous les threads de tous les processus sont inactifs, alors :</p>
<pre class="prettyprint lang-config">idle_workers = 10</pre>
<p>Nous pouvons calculer le nombre maximum absolu de connexions simultan�es
de deux mani�res :</p>
<pre class="prettyprint lang-config">max_connections = (ThreadsPerChild + (AsyncRequestWorkerFactor * idle_workers)) * ServerLimit
= (10 + (2 * 10)) * 4 = 120
max_connections = (AsyncRequestWorkerFactor + 1) * MaxRequestWorkers
= (2 + 1) * 40 = 120</pre>
</div>
<p>Le r�glage de la directive
<code class="directive">AsyncRequestWorkerFactor</code> n�cessite de conna�tre le
trafic g�r� par httpd pour chaque style d'utilisation sp�cifique ; si vous
modifiez la valeur par d�faut, vous devrez par cons�quent effectuer des
tests approfondis en vous appuyant �troitement sur les donn�es fournies par
<code class="module"><a href="../mod/mod_status.html">mod_status</a></code>.</p>
<p>La directive <code class="directive"><a href="../mod/mpm_common.html#maxrequestworkers">MaxRequestWorkers</a></code> se nommait
<code class="directive">MaxClients</code> 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.</p>
<p>La directive <code class="directive">AsyncRequestWorkerFactor</code>
accepte des valeurs d'argument de type non entier, comme "1.5".</p>
</div>
</div>
<div class="bottomlang">
<p><span>Langues Disponibles: </span><a href="../en/mod/event.html" hreflang="en" rel="alternate" title="English"> en </a> |
<a href="../es/mod/event.html" hreflang="es" rel="alternate" title="Espa�ol"> es </a> |
<a href="../fr/mod/event.html" title="Fran�ais"> fr </a></p>
</div><div class="top"><a href="#page-header"><img src="../images/up.gif" alt="top" /></a></div><div class="section"><h2><a id="comments_section" name="comments_section">Commentaires</a></h2><div class="warning"><strong>Notice:</strong><br />This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed again by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Freenode, or sent to our <a href="http://httpd.apache.org/lists.html">mailing lists</a>.</div>
<script type="text/javascript"><!--//--><![CDATA[//><!--
var comments_shortname = 'httpd';
var comments_identifier = 'http://httpd.apache.org/docs/trunk/mod/event.html';
(function(w, d) {
if (w.location.hostname.toLowerCase() == "httpd.apache.org") {
d.write('<div id="comments_thread"><\/div>');
var s = d.createElement('script');
s.type = 'text/javascript';
s.async = true;
s.src = 'https://comments.apache.org/show_comments.lua?site=' + comments_shortname + '&page=' + comments_identifier;
(d.getElementsByTagName('head')[0] || d.getElementsByTagName('body')[0]).appendChild(s);
}
else {
d.write('<div id="comments_thread">Comments are disabled for this page at the moment.<\/div>');
}
})(window, document);
//--><!]]></script></div><div id="footer">
<p class="apache">Copyright 2018 The Apache Software Foundation.<br />Autoris� sous <a href="http://www.apache.org/licenses/LICENSE-2.0">Apache License, Version 2.0</a>.</p>
<p class="menu"><a href="../mod/">Modules</a> | <a href="../mod/quickreference.html">Directives</a> | <a href="http://wiki.apache.org/httpd/FAQ">FAQ</a> | <a href="../glossary.html">Glossaire</a> | <a href="../sitemap.html">Plan du site</a></p></div><script type="text/javascript"><!--//--><![CDATA[//><!--
if (typeof(prettyPrint) !== 'undefined') {
prettyPrint();
}
//--><!]]></script>
</body></html>
|
