<!DOCTYPE html SYSTEM "about:legacy-compat">
<html lang="fr"><head><META http-equiv="Content-Type" content="text/html; charset=UTF-8">
<meta content="width=device-width, initial-scale=1" name="viewport">
<!--
        XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
              This file is generated from xml source: DO NOT EDIT
        XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
      -->
<title>event - Serveur HTTP Apache Version 2.4</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">
</script>

<link href="../images/favicon.png" 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="https://cwiki.apache.org/confluence/display/httpd/FAQ">FAQ</a> | <a href="../glossary.html">Glossaire</a> | <a href="../sitemap.html">Plan du site</a> | <a href="https://bz.apache.org/bugzilla/enter_bug.cgi?product=Apache%20httpd-2">Signaler un bug</a></p>
<p class="apache">Serveur HTTP Apache Version 2.4</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="https://www.apache.org/">Apache</a> &gt; <a href="https://httpd.apache.org/">Serveur HTTP</a> &gt; <a href="https://httpd.apache.org/docs/">Documentation</a> &gt; <a href="../">Version 2.4</a> &gt; <a href="./">Modules</a></div>
<div id="page-content">
<div id="preamble"><h1>Apache MPM event</h1>
<button aria-label="Toggle language list" class="lang-toggle"><svg xmlns="http://www.w3.org/2000/svg" stroke-width="2" stroke="currentColor" fill="none" viewBox="0 0 24 24" height="16" width="16"><circle r="10" cy="12" cx="12"/><line y2="12" x2="22" y1="12" x1="2"/><path d="M12 2a15.3 15.3 0 0 1 4 10 15.3 15.3 0 0 1-4 10 15.3 15.3 0 0 1-4-10 15.3 15.3 0 0 1 4-10z"/></svg></button>
<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="../fr/mod/event.html" title="Fran&ccedil;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&ccedil;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&nbsp;de&nbsp;Module:</a></th><td>mpm_event_module</td></tr>
<tr><th><a href="module-dict.html#SourceFile">Fichier&nbsp;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 con&ccedil;u
    pour permettre le traitement d'un nombre accru de requ&ecirc;tes
    simultan&eacute;es en d&eacute;l&eacute;guant certaines t&acirc;ches
    aux threads d'&eacute;coute, lib&eacute;rant par l&agrave;-m&ecirc;me les
    threads de travail et leur permettant de traiter les nouvelles requ&ecirc;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&eacute;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&egrave;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>
</ul></div>
<div class="top"><a href="#page-header"><img alt="top" src="../images/up.gif"></a></div>
<div class="section">
<h2 id="event-worker-relationship">Relations avec le MPM Worker <a title="Lien permanent" href="#event-worker-relationship" class="permalink">&para;</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&eacute;mente un serveur hybride multi-processus et multi-threads. Un processus de
contr&ocirc;le unique (le parent) est charg&eacute; de lancer des processus enfants. Chaque
processus enfant cr&eacute;e un nombre de threads serveurs d&eacute;fini via la directive
<code class="directive"><a href="../mod/mpm_common.html#threadsperchild">ThreadsPerChild</a></code>, ainsi qu'un thread
d'&eacute;coute qui surveille les requ&ecirc;tes entrantes et les distribue aux threads de
travail pour traitement au fur et &agrave; mesure de leur arriv&eacute;e.</p>

<p>Les directives de configuration &agrave; l'ex&eacute;cution sont identiques &agrave; 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 id="how-it-works">Comment tout cela fonctionne <a title="Lien permanent" href="#how-it-works" class="permalink">&para;</a></h2>
    
    <p>Ce module MPM tente de r&eacute;soudre le "probl&egrave;me keep
    alive" de HTTP. Lorsqu'un client a effectu&eacute; une premi&egrave;re requ&ecirc;te, il peut
    garder la connexion ouverte et envoyer les requ&ecirc;tes suivante en utilisant le
    m&ecirc;me socket, ce qui diminue consid&eacute;rablement la charge qui aurait &eacute;t&eacute;
    induite par la cr&eacute;ation de nouvelles connexions TCP. Cependant, le
    fonctionnement du serveur HTTP Apache impose de r&eacute;server un couple processus
    enfant/thread pour attendre les donn&eacute;es en provenance du client, ce qui
    pr&eacute;sente certains inconv&eacute;nients.     
    Pour r&eacute;soudre ce probl&egrave;me, le MPM Event utilise un thread d'&eacute;coute d&eacute;di&eacute;
    pour chaque processus pour g&eacute;rer les sockets d'&eacute;coute, tous les sockets qui
    sont dans un &eacute;tat de connexion persistante, les sockets o&ugrave; les
    filtres de gestionnaire et de protocole ont fait leur travail, et ceux pour
    lesquels la seule chose restant &agrave; faire est l'envoi des donn&eacute;es au client.
    </p>

    <p>Cette nouvelle architecture, en exploitant les sockets non blocants et
    les fonctionnalit&eacute;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
    &eacute;viter le probl&egrave;me de "thundering herd".</p>

    <p>La directive <code class="directive">AsyncRequestWorkerFactor</code> permet de
    d&eacute;finir le nombre total de connexions qu'un bloc processus/thread peut
    g&eacute;rer.</p>

    <h3 id="async-connections">Connexions asynchrones</h3>
        <p>Avec les MPM pr&eacute;c&eacute;dents, les connexions asynchrones n&eacute;cessitaient
	un thread de travail d&eacute;di&eacute;, mais ce n'est plus le cas avec le MPM Event.
	La page d'&eacute;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&eacute;ponse au client, il peut arriver que le
	    tampon d'&eacute;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&eacute;n&eacute;ral <code>EWOULDBLOCK</code> ou <code>EAGAIN</code>
	    pour que l'on puisse y &eacute;crire &agrave; nouveau apr&egrave;s un certain temps
	    d'inactivit&eacute;. Le thread de travail qui utilise le socket doit alors
	    &ecirc;tre en mesure de r&eacute;cup&eacute;rer la t&acirc;che en attente et la restituer au
	    thread d'&eacute;coute qui, &agrave; son tour, la r&eacute;attribuera au premier thread
	    de travail disponible, lorsqu'un &eacute;v&egrave;nement sera g&eacute;n&eacute;r&eacute; pour le socket
	    (par exemple, "il est maintenant possible d'&eacute;crire dans le socket").
	    Veuillez vous reporter &agrave; la section &agrave; propos des limitations pour
	    plus de d&eacute;tails.
            </dd>

            <dt>Keep-alive</dt>
            <dd>La gestion des connexions persistantes constitue la principale
	    am&eacute;lioration par rapport au MPM Worker. Lorsqu'un thread de travail
	    a termin&eacute; l'envoi d'une r&eacute;ponse &agrave; un client, il peut restituer la
	    gestion du socket au thread d'&eacute;coute, qui &agrave; son tour va attendre un
	    &eacute;v&egrave;nement en provenance du syst&egrave;me d'exploitation comme "le socket
	    est lisible". Si une nouvelle requ&ecirc;te arrive en provenance du
	    client, le thread d'&eacute;coute l'attribuera au premier thread de travail
	    disponible. Inversement, si le d&eacute;lai <code class="directive"><a href="../mod/core.html#keepalivetimeout">KeepAliveTimeout</a></code> est atteint, le socket
	    sera ferm&eacute; par le thread d'&eacute;coute. Les threads de travail n'ont
	    donc plus &agrave; s'occuper des sockets inactifs et ils peuvent &ecirc;tre
	    r&eacute;utilis&eacute;s pour traiter d'autres requ&ecirc;tes.</dd>

            <dt>Closing</dt>
            <dd>Parfois, le MPM doit effectuer une fermeture progressive, c'est
	    &agrave; dire envoyer au client une erreur survenue pr&eacute;c&eacute;demment alors que
	    ce dernier est en train de transmettre des donn&eacute;es &agrave; httpd. Envoyer la r&eacute;ponse et
	    fermer imm&eacute;diatement la connexion n'est pas une bonne solution car
	    le client (qui est encore en train d'envoyer le reste de la requ&ecirc;te)
	    verrait sa connexion r&eacute;initialis&eacute;e et ne pourrait pas lire la
	    r&eacute;ponse de httpd. La fermeture progressive est limit&eacute;e dans le temps,
	    mais elle peut tout de m&ecirc;me &ecirc;tre assez longue, si bien qu'elle est
	    confi&eacute;e &agrave; un thread de travail (y compris les proc&eacute;dures d'arr&ecirc;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&eacute;passer
	    leur d&eacute;lai d'attente (le thread d'&eacute;coute ne g&egrave;re jamais les
	    connexions, si ce n'est attendre et dispatcher les &eacute;v&egrave;nements
	    qu'elles g&eacute;n&egrave;rent).</dd>
        </dl>

        <p>Ces am&eacute;liorations sont disponible pour les connexions HTTP ou HTTPS.</p> 

    

    <h3 id="graceful-close">Arr&ecirc;t de processus en douceur et
    utilisation du scoreboard</h3>
        <p>Ce MPM pr&eacute;sentait dans le pass&eacute; des limitations de mont&eacute;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&ecirc;tes pouvant &ecirc;tre servies simultan&eacute;ment &agrave; un moment donn&eacute;
	ainsi que le nombre de processus autoris&eacute;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&eacute;sente l'ensemble des processus en cours d'ex&eacute;cution et
	l'&eacute;tat de leurs threads de travail. Si le scoreboard est plein
	(autrement dit si aucun des threads n'est dans un &eacute;tat inactif) et si le
	nombre de requ&ecirc;tes actives servies est inf&eacute;rieur &agrave; <code class="directive"><a href="../mod/mpm_common.html#maxrequestworkers">MaxRequestWorkers</a></code>, cela signifie que
	certains d'entre eux bloquent les nouvelles requ&ecirc;tes qui pourraient &ecirc;tre
	servies et sont en l'occurrence mises en attente (dans la limite de la
	valeur impos&eacute;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&eacute;s dans un &eacute;tat d'arr&ecirc;t en douceur car ils attendent
	de terminer leur travail sur une connexion TCP pour s'arr&ecirc;ter et ainsi lib&eacute;rer
	une entr&eacute;e dans le scoreboard (par exemple dans le cas du traitement des
	requ&ecirc;tes de longue dur&eacute;e, des clients lents ou des connexions en
	keep-alive). Voici deux sc&eacute;narios courants :</p>
        <ul>
            <li>Pendant un <a href="../stopping.html#graceful">graceful
	    restart</a>, le processus parent demande &agrave; tous ses processus
	    enfants de terminer leur travail et de s'arr&ecirc;ter pendant qu'il
	    recharge la configuration et lance de nouveaux processus. Si les
	    processus existants continuent de s'ex&eacute;cuter pendant un certain
	    temps avant de s'arr&ecirc;ter, le scoreboard sera partiellement occup&eacute;
	    jusqu'&agrave; ce que les entr&eacute;es correspondantes soient lib&eacute;r&eacute;es.
            </li>
            <li>Lorsque la charge du serveur diminue suffisamment pour que httpd
	    commence &agrave; 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&egrave;matique car lorsque la charge augmente &agrave; nouveau, httpd va
	    essayer de lancer de nouveaux processus. Si cette situation se
	    r&eacute;p&egrave;te, le nombre de processus peut augmenter sensiblement,
	    aboutissant &agrave; un m&eacute;lange d'anciens processus tentant de s'arr&ecirc;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&ecirc;ts graceful de mani&egrave;re plus efficace. Voici certaines de
	ces am&eacute;liorations :</p>
        <ul>
            <li>Utilisation de toutes les entr&eacute;es du scoreboard dans la limite
	    de la valeur d&eacute;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&ecirc;t graceful pour
	    permettre l'utilisation d'entr&eacute;es suppl&eacute;mentaires du scoreboard en
	    cas de besoin. L'id&eacute;e consiste &agrave; utiliser <code class="directive"><a href="../mod/mpm_common.html#serverlimit">ServerLimit</a></code> pour indiquer &agrave; httpd
	    conbien de processus suppl&eacute;mentaires seront tol&eacute;r&eacute;s avant
	    d'atteindre les limites impos&eacute;es par les ressources du syst&egrave;me.
            </li>
            <li>Les processus en arr&ecirc;t graceful doivent fermer leurs connexions
	    en keep-alive.</li>
            <li>Lors d'un arr&ecirc;t graceful, s'il y a plus de threads de travail en
	    cours d'ex&eacute;cution que de connexions ouvertes pour un processus
	    donn&eacute;, ces threads sont arr&ecirc;t&eacute;s afin de lib&eacute;rer les ressources plus
	    vite (ce qui peut s'av&eacute;rer n&eacute;cessaire pour lancer de nouveaux
	    processus).</li>
            <li>Si le scoreboard est plein, emp&ecirc;che d'arr&ecirc;ter d'autres processus
	    en mode graceful afin de r&eacute;duire la charge jusqu'&agrave; ce que tous les
	    anciens processus soient arr&ecirc;t&eacute;s (sinon la situation empirerait lors
	    d'une remont&eacute;e en charge).</li>
        </ul>
        <p>Le comportement d&eacute;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&egrave;re indique le PID et
	la seconde si le processus est en cours d'arr&ecirc;t ou non ; l'&eacute;tat
	suppl&eacute;mentaire "Yes (old gen)" indique un processus encore en ex&eacute;cution
	apr&egrave;s un red&eacute;marrage graceful.</p>
    

    <h3 id="limitations">Limitations</h3>
        <p>La gestion am&eacute;lior&eacute;e des connexions peut ne pas fonctionner pour
	certains filtres de connexion qui se sont d&eacute;clar&eacute;s eux-m&ecirc;mes
	incompatibles avec le MPM Event. Dans ce cas, le MPM Event r&eacute;adoptera le
	comportement du MPM <code class="module"><a href="../mod/worker.html">worker</a></code> et r&eacute;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&icirc;t lorsqu'une requ&ecirc;te utilise un
	filtre en sortie qui doit pouvoir lire et/ou modifier la totalit&eacute; du
	corps de la r&eacute;ponse. Si la connexion avec le client se bloque pendant
	que le filtre traite les donn&eacute;es, et si la quantit&eacute; de donn&eacute;es produites
	par le filtre est trop importante pour &ecirc;tre stock&eacute;e en m&eacute;moire, le
	thread utilis&eacute; pour la requ&ecirc;te n'est pas lib&eacute;r&eacute; pendant que httpd attend
	que les donn&eacute;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&eacute;. La premi&egrave;re situation est pr&eacute;visible ; en effet, le MPM Event a
	une parfaite visibilit&eacute; sur la fin du contenu, et il peut utiliser les
	&eacute;v&egrave;nements : le thread de travail qui sert la r&eacute;ponse peut envoyer les
	premiers octets jusqu'&agrave; ce que <code>EWOULDBLOCK</code> ou
	<code>EAGAIN</code> soit renvoy&eacute;, et d&eacute;l&eacute;guer le reste de la r&eacute;ponse au thread
	d'&eacute;coute. Ce dernier en retour attend un &eacute;v&egrave;nement sur le socket, et
	d&eacute;l&egrave;gue le reste de la r&eacute;ponse au premier
	thread de travail disponible. Dans la deuxi&egrave;me situation par contre
	(FCGI/CGI/contenu mandat&eacute;), le MPM n'a pas de visibilit&eacute; sur la fin de
	la r&eacute;ponse, et le thread de travail doit terminer sa t&acirc;che avant de
	rendre le contr&ocirc;le au thread d'&eacute;coute. La seule solution consisterait
	alors &agrave; stocker la r&eacute;ponse en m&eacute;moire, mais ce ne serait pas l'option la
	plus sure en mati&egrave;re de stabilit&eacute; du serveur et d'empreinte m&eacute;moire.
        </p>

    

    <h3 id="background">Mat&eacute;riel d'arri&egrave;re-plan</h3>
        <p>Le mod&egrave;le event a &eacute;t&eacute; rendu possible par l'introduction de nouvelles
	APIs dans les syst&egrave;mes d'exploitation support&eacute;s :</p>
        <ul>
            <li>epoll (Linux) </li>
            <li>kqueue (BSD) </li>
            <li>event ports (Solaris) </li>
        </ul>
        <p>Avant que ces APIs soient mises &agrave; disposition, les APIs
	traditionnelles <code>select</code> et <code>poll</code> devaient &ecirc;tre
	utilis&eacute;es. Ces APIs deviennent lentes si on les utilise pour g&eacute;rer de
	nombreuses connexions ou si le jeu de connexions poss&egrave;de un taux de
	renouvellement &eacute;lev&eacute;. Les nouvelles APIs permettent de g&eacute;rer beaucoup
	plus de connexions et leur performances sont meilleures lorsque le jeu
	de connexions &agrave; g&eacute;rer change fr&eacute;quemment. Ces APIs ont donc rendu
	possible l'&eacute;criture le MPM Event qui est mieux adapt&eacute; &agrave; la situation
	HTTP typique o&ugrave; de nombreuses connexions sont inactives.</p>

        <p>Le MPM Event suppose que l'impl&eacute;mentation de <code>apr_pollset</code>
	sous-jacente est raisonnablement sure avec l'utilisation des threads
	(threadsafe). Ceci &eacute;vite au MPM de devoir effectuer trop verrouillages
	de haut niveau, ou d'avoir &agrave; r&eacute;veiller le thread d'&eacute;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 id="requirements">Pr&eacute;requis <a title="Lien permanent" href="#requirements" class="permalink">&para;</a></h2>
    <p>Ce MPM d&eacute;pend des op&eacute;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 &agrave; APR
    d'impl&eacute;menter les op&eacute;rations atomiques en utilisant des instructions
    performantes indisponibles avec les processeurs plus
    anciens.</p>

    <p>Ce MPM ne fonctionne pas de mani&egrave;re optimale sur les
    plates-formes plus anciennes qui ne g&egrave;rent pas correctement les
    threads, mais ce probl&egrave;me est sans objet du fait du pr&eacute;requis
    concernant EPoll ou KQueue.</p>

    <ul>

      <li>Pour utiliser ce MPM sous FreeBSD, la version 5.3 ou
      sup&eacute;rieure de ce syst&egrave;me est recommand&eacute;e. Il est cependant
      possible d'ex&eacute;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&eacute;rieure.</li>

      <li>Pour Linux, un noyau 2.6 est recommand&eacute;. Il faut aussi
      s'assurer que votre version de <code>glibc</code> a &eacute;t&eacute; compil&eacute;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 id="asyncrequestworkerfactor">Directive <span id="AsyncRequestWorkerFactor">AsyncRequestWorkerFactor</span> <a title="Lien permanent" href="#asyncrequestworkerfactor" class="permalink">&para;</a></h2>
<table class="directive">
<tr><th><a href="directive-dict.html#Description">Description:</a></th><td>Limite le nombre de connexions simultan&eacute;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&eacute;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&eacute;:</a></th><td>Disponible depuis la version 2.3.13</td></tr>
</table>
    <p>Le MPM event g&egrave;re certaines connexions de mani&egrave;re asynchrone ;
    dans ce cas, les threads traitant la requ&ecirc;te sont allou&eacute;s selon les
    besoins et pour de courtes p&eacute;riodes. Dans les autres cas, un
    thread est r&eacute;serv&eacute; par
    connexion. Ceci peut conduire &agrave; des situations o&ugrave; tous les threads
    sont satur&eacute;s et o&ugrave; aucun thread n'est capable d'effectuer de
    nouvelles t&acirc;ches pour les connexions asynchrones &eacute;tablies.</p>

    <p>Pour minimiser les effets de ce probl&egrave;me, le MPM event utilise
    deux m&eacute;thodes :</p>
    <ul>
    	<li>il limite le nombre de connexions
	    simultan&eacute;es par thread en fonction du nombre de processus
	    inactifs;</li>
	<li>si tous les processus sont occup&eacute;s, il ferme des connexions
	permanentes, m&ecirc;me si la limite de dur&eacute;e de la connexion n'a
	pas &eacute;t&eacute; atteinte. Ceci autorise les clients
	concern&eacute;s &agrave; se reconnecter &agrave; un autre processus
	poss&egrave;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 &agrave; l'&eacute;tat "closing") est
    inf&eacute;rieur &agrave; :</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&eacute;es pour tous les processus et pour un nombre donn&eacute; 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&eacute;es peut &ecirc;tre calcul&eacute; de mani&egrave;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&eacute;es
    de deux mani&egrave;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&eacute;glage de la directive
    <code class="directive">AsyncRequestWorkerFactor</code> n&eacute;cessite de conna&icirc;tre le
    trafic g&eacute;r&eacute; par httpd pour chaque style d'utilisation sp&eacute;cifique ; si vous
    modifiez la valeur par d&eacute;faut, vous devrez par cons&eacute;quent effectuer des
    tests approfondis en vous appuyant &eacute;troitement sur les donn&eacute;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 &agrave; 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="../fr/mod/event.html" title="Fran&ccedil;ais">&nbsp;fr&nbsp;</a></p>
</div><div id="footer">
<p class="apache">Copyright 2026 The Apache Software Foundation.<br>Autoris&eacute; sous <a href="https://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="https://cwiki.apache.org/confluence/display/httpd/FAQ">FAQ</a> | <a href="../glossary.html">Glossaire</a> | <a href="../sitemap.html">Plan du site</a> | <a href="https://bz.apache.org/bugzilla/enter_bug.cgi?product=Apache%20httpd-2">Signaler un bug</a></p></div><script><!--//--><![CDATA[//><!--
if (typeof(prettyPrint) !== 'undefined') {
    prettyPrint();
}
var langToggle = document.querySelector('.lang-toggle');
var topLang = document.querySelector('.toplang');
if (langToggle && topLang) {
    langToggle.addEventListener('click', function() { topLang.classList.toggle('open'); });
}
var qv = document.getElementById('quickview');
if (qv) {
    document.body.appendChild(qv);
    var qvBtn = document.createElement('button');
    qvBtn.className = 'qv-toggle';
    qvBtn.setAttribute('aria-label', 'Toggle page navigation');
    qvBtn.innerHTML = '&#9776;';
    document.body.appendChild(qvBtn);
    qvBtn.addEventListener('click', function() {
        var isOpen = qv.classList.toggle('open');
        if (isOpen) {
            qv.style.top = window.scrollY + 10 + 'px';
        }
    });
    window.addEventListener('scroll', function() { qv.classList.remove('open'); });
}
//--><!]]></script>
</body></html>