www/apache
1
0
Fork 0
mirror of https://github.com/apache/httpd.git synced 2025-11-02 06:53:27 +03:00
Code Activity
Files
4aad89fe8073796ac0b358ff7cc3b1b366e8b51b
apache/docs/manual/mod/event.html.fr
Lucien Gentis 35cb06a33a Rebuild. 
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1820120 13f79535-47bb-0310-9956-ffa450edef68
2018-01-04 16:30:17 +00:00

518 lines
32 KiB
Plaintext
Raw Blame History

<?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="&lt;-" alt="&lt;-" src="../images/left.gif" /></a></div>
<div id="path">
<a href="http://www.apache.org/">Apache</a> &gt; <a href="http://httpd.apache.org/">Serveur HTTP</a> &gt; <a href="http://httpd.apache.org/docs/">Documentation</a> &gt; <a href="../">Version 2.5</a> &gt; <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">&nbsp;en&nbsp;</a> |
<a href="../es/mod/event.html" hreflang="es" rel="alternate" title="Espa<70>ol">&nbsp;es&nbsp;</a> |
<a href="../fr/mod/event.html" title="Fran<61>ais">&nbsp;fr&nbsp;</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<6F>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<75>de<64>Module:</a></th><td>mpm_event_module</td></tr>
<tr><th><a href="module-dict.html#SourceFile">Fichier<65>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<70>mentation asynchrone bas<61>e sur les <20>v<EFBFBD>nements et con<6F>u
pour permettre le traitement d'un nombre accru de requ<71>tes
simultan<61>es en d<>l<EFBFBD>guant certaines t<>ches
aux threads d'<27>coute, lib<69>rant par l<>-m<>me les
threads de travail et leur permettant de traiter les nouvelles requ<71>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<50>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__&amp;list_id=144532&amp;product=Apache%20httpd-2&amp;query_format=specific&amp;order=changeddate%20DESC%2Cpriority%2Cbug_severity&amp;component=mpm_event">Probl<62>mes connus</a></li><li><a href="https://bz.apache.org/bugzilla/enter_bug.cgi?product=Apache%20httpd-2&amp;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></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<EFBFBD>mente un serveur hybride multi-processus et multi-threads. Un processus de
contr<EFBFBD>le unique (le parent) est charg<72> de lancer des processus enfants. Chaque
processus enfant cr<63>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'<27>coute qui surveille les requ<71>tes entrantes et les distribue aux threads de
travail pour traitement au fur et <20> mesure de leur arriv<69>e.</p>
<p>Les directives de configuration <20> l'ex<65>cution sont identiques <20> 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 <20>t<EFBFBD> con<6F>u <20> l'origine pour r<>soudre le "probl<62>me keep
alive" de HTTP. Lorsqu'un client a effectu<74> une premi<6D>re requ<71>te, il peut
garder la connexion ouverte et envoyer les requ<71>tes suivante en utilisant le
m<>me socket, ce qui diminue consid<69>rablement la charge qui aurait <20>t<EFBFBD>
induite par la cr<63>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<6E>es en provenance du client, ce qui
pr<70>sente certains inconv<6E>nients. Pour r<>soudre ce probl<62>me, le MPM Event
utilise un thread d'<27>coute d<>di<64> pour chaque processus associ<63> <20> un jeu de
threads de travail, partageant les files d'attentes sp<73>cifiques aux
requ<71>tes en mode keep-alive (ou plus simplement en mode "lisible"), <20> celles
en mode <20>criture des r<>sultats, et <20> celles en court de fermeture
("closing"). Une boucle d'attente d'<27>v<EFBFBD>nements d<>clench<63>e en fonction du
statut de la disponibilit<69> 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<69>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
<20>viter le probl<62>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<70>c<EFBFBD>dents, les connexions asynchrones n<>cessitaient
un thread de travail d<>di<64>, mais ce n'est plus le cas avec le MPM Event.
La page d'<27>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'<27>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<EFBFBD>ral <code>EWOULDBLOCK</code> ou <code>EAGAIN</code>
pour que l'on puisse y <20>crire <20> nouveau apr<70>s un certain temps
d'inactivit<69>. Le thread de travail qui utilise le socket doit alors
<20>tre en mesure de r<>cup<75>rer la t<>che en attente et la restituer au
thread d'<27>coute qui, <20> son tour, la r<>attribuera au premier thread
de travail disponible, lorsqu'un <20>v<EFBFBD>nement sera g<>n<EFBFBD>r<EFBFBD> pour le socket
(par exemple, "il est maintenant possible d'<27>crire dans le socket").
Veuillez vous reporter <20> la section <20> propos des limitations pour
plus de d<>tails.
</dd>
<dt>Keep-alive</dt>
<dd>La gestion des connexions persistantes constitue la principale
am<61>lioration par rapport au MPM Worker. Lorsqu'un thread de travail
a termin<69> l'envoi d'une r<>ponse <20> un client, il peut restituer la
gestion du socket au thread d'<27>coute, qui <20> son tour va attendre un
<20>v<EFBFBD>nement en provenance du syst<73>me d'exploitation comme "le socket
est lisible". Si une nouvelle requ<71>te arrive en provenance du
client, le thread d'<27>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<72> par le thread d'<27>coute. Les threads de travail n'ont
donc plus <20> s'occuper des sockets inactifs et ils peuvent <20>tre
r<>utilis<69>s pour traiter d'autres requ<71>tes.</dd>
<dt>Closing</dt>
<dd>Parfois, le MPM doit effectuer une fermeture progressive, c'est
<20> dire envoyer au client une erreur survenue pr<70>c<EFBFBD>demment alors que
ce dernier est en train de transmettre des donn<6E>es <20> httpd. Envoyer la r<>ponse et
fermer imm<6D>diatement la connexion n'est pas une bonne solution car
le client (qui est encore en train d'envoyer le reste de la requ<71>te)
verrait sa connexion r<>initialis<69>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<71>te afin de permettre au client de lire la r<>ponse
enti<74>rement. La fermeture progressive est limit<69>e dans le temps,
mais elle peut tout de m<>me <20>tre assez longue, si bien qu'il est
int<6E>ressant qu'un thread de travail puisse se d<>charger de cette
t<>che sur le thread d'<27>coute. A partir de la version 2.4.28, au lieu
d'effectuer lui-m<>me la fermeture progressive, le thread d'<27>coute
confie cette t<>che au premier thread de travail disponible.</dd>
</dl>
<p>Ces am<61>liorations sont disponible pour les connexions HTTP ou HTTPS.</p>
<p>Les <20>tats de connexions ci-dessus sont g<>r<EFBFBD>s par le thread d'<27>coute
via des files d'attente d<>di<64>es qui, jusqu'<27> la version 2.4.27, <20>taient
lues toutes les 100ms pour d<>terminer quelles connexions avaient atteint
des limites de dur<75>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'<27>tait une solution simple
et efficace mais qui pr<70>sentait un inconv<6E>nient : ces lectures
r<>guli<6C>res for<6F>aient le thread d'<27>coute <20> se r<>veiller, souvent sans
n<>cessit<69> (alors qu'il <20>tait totalement inactif), ce qui consommait des
ressources pour rien. A partir de la version 2.4.28, ces files d'attente
sont enti<74>rement g<>r<EFBFBD>es selon une logique bas<61>es sur les <20>v<EFBFBD>nements, et
ne font donc plus l'objet d'une lecture syst<73>matique. Les environnements
aux ressources limit<69>es, comme les serveurs embarqu<71>s, seront les plus
grands b<>n<EFBFBD>ficiaires de cette am<61>lioration.</p>
<h3><a name="graceful-close" id="graceful-close">Arr<72>t de processus en douceur et
utilisation du scoreboard</a></h3>
<p>Ce MPM pr<70>sentait dans le pass<73> des limitations de mont<6E>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<71>tes pouvant <20>tre servies simultan<61>ment <20> un moment donn<6E>
ainsi que le nombre de processus autoris<69>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<70>sente l'ensemble des processus en cours d'ex<65>cution et
l'<27>tat de leurs threads de travail. Si le scoreboard est plein
(autrement dit si aucun des threads n'est dans un <20>tat inactif) et si le
nombre de requ<71>tes actives servies est inf<6E>rieur <20> <code class="directive"><a href="../mod/mpm_common.html#maxrequestworkers">MaxRequestWorkers</a></code>, cela signifie que
certains d'entre eux bloquent les nouvelles requ<71>tes qui pourraient <20>tre
servies et sont en l'occurrence mises en attente (dans la limite de la
valeur impos<6F>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<71>s dans un <20>tat d'arr<72>t en douceur car ils attendent
de terminer leur travail sur une connexion TCP pour s'arr<72>ter et ainsi lib<69>rer
une entr<74>e dans le scoreboard (par exemple dans le cas du traitement des
requ<71>tes de longue dur<75>e, des clients lents ou des connexions en
keep-alive). Voici deux sc<73>narios courants :</p>
<ul>
<li>Pendant un <a href="../stopping.html#graceful">graceful
restart</a>. Le processus parent demande <20> tous ses processus
enfants de terminer leur travail et de s'arr<72>ter pendant qu'il
recharge la configuration et lance de nouveaux processus. Si les
processus existants continuent de s'ex<65>cuter pendant un certain
temps avant de s'arr<72>ter, le scoreboard sera partiellement occup<75>
jusqu'<27> ce que les entr<74>es correspondantes soient lib<69>r<EFBFBD>es.
</li>
<li>Lorsque la charge du serveur diminue suffisamment pour que httpd
commence <20> 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<62>matique car lorsque la charge augmente <20> nouveau, httpd va
essayer de lancer de nouveaux processus. Si cette situation se
r<>p<EFBFBD>te, le nombre de processus peut augmenter sensiblement,
aboutissant <20> un m<>lange d'anciens processus tentant de s'arr<72>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<72>ts graceful de mani<6E>re plus efficace. Voici certaines de
ces am<61>liorations :</p>
<ul>
<li>Utilisation de toutes les entr<74>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<72>t graceful pour
permettre l'utilisation d'entr<74>es suppl<70>mentaires du scoreboard en
cas de besoin. L'id<69>e consiste <20> utiliser <code class="directive"><a href="../mod/mpm_common.html#serverlimit">ServerLimit</a></code> pour indiquer <20> httpd
conbien de processus suppl<70>mentaires seront tol<6F>r<EFBFBD>s avant
d'atteindre les limites impos<6F>es par les ressources du syst<73>me.
</li>
<li>Les processus en arr<72>t graceful doivent fermer leurs connexions
en keep-alive.</li>
<li>Lors d'un arr<72>t graceful, s'il y a plus de threads de travail en
cours d'ex<65>cution que de connexions ouvertes pour un processus
donn<6E>, ces threads sont arr<72>t<EFBFBD>s afin de lib<69>rer les ressources plus
vite (ce qui peut s'av<61>rer n<>cessaire pour lancer de nouveaux
processus).</li>
<li>Si le scoreboard est plein, emp<6D>che d'arr<72>ter d'autres processus
en mode graceful afin de r<>duire la charge jusqu'<27> ce que tous les
anciens processus soient arr<72>t<EFBFBD>s (sinon la situation empirerait lors
d'une remont<6E>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<6D>re indique le PID et
la seconde si le processus est en cours d'arr<72>t ou non ; l'<27>tat
suppl<70>mentaire "Yes (old gen)" indique un processus encore en ex<65>cution
apr<70>s un red<65>marrage graceful.</p>
<h3><a name="limitations" id="limitations">Limitations</a></h3>
<p>La gestion am<61>lior<6F>e des connexions peut ne pas fonctionner pour
certains filtres de connexion qui se sont d<>clar<61>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<72>t lorsqu'une requ<71>te utilise un
filtre en sortie qui doit pouvoir lire et/ou modifier la totalit<69> du
corps de la r<>ponse. Si la connexion avec le client se bloque pendant
que le filtre traite les donn<6E>es, et si la quantit<69> de donn<6E>es produites
par le filtre est trop importante pour <20>tre stock<63>e en m<>moire, le
thread utilis<69> pour la requ<71>te n'est pas lib<69>r<EFBFBD> pendant que httpd attend
que les donn<6E>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<61>. La premi<6D>re situation est pr<70>visible ; en effet, le MPM Event a
une parfaite visibilit<69> sur la fin du contenu, et il peut utiliser les
<09>v<EFBFBD>nements : le thread de travail qui sert la r<>ponse peut envoyer les
premiers octets jusqu'<27> ce que <code>EWOULDBLOCK</code> ou
<code>EAGAIN</code> soit renvoy<6F>, et d<>l<EFBFBD>guer le reste de la r<>ponse au thread
d'<27>coute. Ce dernier en retour attend un <20>v<EFBFBD>nement sur le socket, et
d<>l<EFBFBD>gue le reste de la r<>ponse au premier
thread de travail disponible. Dans la deuxi<78>me situation par contre
(FCGI/CGI/contenu mandat<61>), le MPM n'a pas de visibilit<69> sur la fin de
la r<>ponse, et le thread de travail doit terminer sa t<>che avant de
rendre le contr<74>le au thread d'<27>coute. La seule solution consisterait
alors <20> stocker la r<>ponse en m<>moire, mais ce ne serait pas l'option la
plus sure en mati<74>re de stabilit<69> du serveur et d'empreinte m<>moire.
</p>
<h3><a name="background" id="background">Mat<61>riel d'arri<72>re-plan</a></h3>
<p>Le mod<6F>le event a <20>t<EFBFBD> rendu possible par l'introduction de nouvelles
APIs dans les syst<73>mes d'exploitation support<72>s :</p>
<ul>
<li>epoll (Linux) </li>
<li>kqueue (BSD) </li>
<li>event ports (Solaris) </li>
</ul>
<p>Avant que ces APIs soient mises <20> disposition, les APIs
traditionnelles <code>select</code> et <code>poll</code> devaient <20>tre
utilis<69>es. Ces APIs deviennent lentes si on les utilise pour g<>rer de
nombreuses connexions ou si le jeu de connexions poss<73>de un taux de
renouvellement <20>lev<65>. Les nouvelles APIs permettent de g<>rer beaucoup
plus de connexions et leur performances sont meilleures lorsque le jeu
de connexions <20> g<>rer change fr<66>quemment. Ces APIs ont donc rendu
possible l'<27>criture le MPM Event qui est mieux adapt<70> <20> la situation
HTTP typique o<> de nombreuses connexions sont inactives.</p>
<p>Le MPM Event suppose que l'impl<70>mentation de <code>apr_pollset</code>
sous-jacente est raisonnablement sure avec l'utilisation des threads
(threadsafe). Ceci <20>vite au MPM de devoir effectuer trop verrouillages
de haut niveau, ou d'avoir <20> r<>veiller le thread d'<27>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<50>requis</a></h2>
<p>Ce MPM d<>pend des op<6F>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 <20> APR
d'impl<70>menter les op<6F>rations atomiques en utilisant des instructions
performantes indisponibles avec les processeurs plus
anciens.</p>
<p>Ce MPM ne fonctionne pas de mani<6E>re optimale sur les
plates-formes plus anciennes qui ne g<>rent pas correctement les
threads, mais ce probl<62>me est sans objet du fait du pr<70>requis
concernant EPoll ou KQueue.</p>
<ul>
<li>Pour utiliser ce MPM sous FreeBSD, la version 5.3 ou
sup<75>rieure de ce syst<73>me est recommand<6E>e. Il est cependant
possible d'ex<65>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<75>rieure.</li>
<li>Pour Linux, un noyau 2.6 est recommand<6E>. Il faut aussi
s'assurer que votre version de <code>glibc</code> a <20>t<EFBFBD> compil<69>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<61>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<69>:</a></th><td>Disponible depuis la version 2.3.13</td></tr>
</table>
<p>Le MPM event g<>re certaines connexions de mani<6E>re asynchrone ;
dans ce cas, les threads traitant la requ<71>te sont allou<6F>s selon les
besoins et pour de courtes p<>riodes. Dans les autres cas, un
thread est r<>serv<72> par
connexion. Ceci peut conduire <20> des situations o<> tous les threads
sont satur<75>s et o<> aucun thread n'est capable d'effectuer de
nouvelles t<>ches pour les connexions asynchrones <20>tablies.</p>
<p>Pour minimiser les effets de ce probl<62>me, le MPM event utilise
deux m<>thodes :</p>
<ul>
<li>il limite le nombre de connexions
simultan<61>es par thread en fonction du nombre de processus
inactifs;</li>
<li>si tous les processus sont occup<75>s, il ferme des connexions
permanentes, m<>me si la limite de dur<75>e de la connexion n'a
pas <20>t<EFBFBD> atteinte. Ceci autorise les clients
concern<72>s <20> se reconnecter <20> un autre processus
poss<73>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 <20> l'<27>tat "closing") est
inf<6E>rieur <20> :</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<61>es pour tous les processus et pour un nombre donn<6E> 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<61>es peut <20>tre calcul<75> de mani<6E>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<61>es
de deux mani<6E>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<6E>tre le
trafic g<>r<EFBFBD> par httpd pour chaque style d'utilisation sp<73>cifique ; si vous
modifiez la valeur par d<>faut, vous devrez par cons<6E>quent effectuer des
tests approfondis en vous appuyant <20>troitement sur les donn<6E>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 <20> 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">&nbsp;en&nbsp;</a> |
<a href="../es/mod/event.html" hreflang="es" rel="alternate" title="Espa<70>ol">&nbsp;es&nbsp;</a> |
<a href="../fr/mod/event.html" title="Fran<61>ais">&nbsp;fr&nbsp;</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&amp;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<69> 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>
View Git Blame Copy Permalink