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
|
<?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 Apache HTTP 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 Apache HTTP 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="../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>R�capitulatif des corrections de bogues</h3><ul class="seealso"><li><a href="http://httpd.apache.org/dev/dist/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">Rapports de bogues ouverts</a></li></ul><h3>Voir aussi</h3>
<ul class="seealso">
<li><a href="worker.html">Le MPM worker</a></li>
</ul><ul class="seealso"><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></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></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>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. Si cela se produit, httpd essaie donc de lire le
reste de la requ�te afin de permettre au client de lire la r�ponse
enti�rement. La fermeture progressive est limit�e dans le temps,
mais elle peut tout de m�me �tre assez longue, si bien qu'il est
int�ressant qu'un thread de travail puisse se d�charger de cette
t�che sur le thread d'�coute.</dd>
</dl>
<p>Ces am�liorations sont disponible pour les connexions HTTP ou HTTPS.</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></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></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 du serveur</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="../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 2016 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>
|
