Update.

<?xml version="1.0"?>

<!DOCTYPE modulesynopsis SYSTEM "../style/modulesynopsis.dtd">

<?xml-stylesheet type="text/xsl" href="../style/manual.fr.xsl"?>

<!-- English Revision : 1137744 -->

<!-- English Revision : 1142490 -->

<!-- French translation : Lucien GENTIS -->

<!-- Reviewed by : Vincent Deffontaines -->

    mobilise en principe à cet effet un processus/thread enfant en

    attente des données du client, ce qui amène son propre lot

    d'inconv&eacute;nients. Pour r&eacute;soudre ce probl&egrave;me, <module>event</module>

    utilise un thread dédié qui gère non seulement les sockets en

    &eacute;coute, mais aussi tous les sockets en &eacute;tat Keep Alive.</p>

    utilise un thread dédié qui gère les sockets en

    écoute, tous les sockets en état Keep Alive, et les

    sockets où les filtres gestionnaires et de protocole ont

    fait leur travail et pour lesquels la seule chose restant à faire

    consiste à envoyer les données au client. La page d'état de

    <module>mod_status</module> montre les connexions qui se trouvent

    dans les situations mentionn&eacute;es.</p>

    <p>Le gestionnaire de connexion am&eacute;lior&eacute; ne fonctionne pas encore

    pour certains filtres de connexion, et en particulier SSL. Pour les

    connexions SSL, ce MPM réadopte le comportement du MPM

    <module>worker</module> et r&eacute;serve un thread par connexion.</p>

    <p>Le MPM pr&eacute;suppose que l'impl&eacute;mentation <code>apr_pollset</code>

    sous-jacente est raisonnablement sûre du point de vue des threads.

<directivesynopsis location="mpm_common"><name>User</name>

</directivesynopsis>

<directivesynopsis>

<name>AsyncRequestWorkerFactor</name>

<description>Limite le nombre de connexions simultan&eacute;es par thread</description>

<syntax>AsyncRequestWorkerFactor <var>facteur</var></syntax>

<default>2</default>

<contextlist><context>server config</context> </contextlist>

<compatibility>Disponible depuis la version 2.3.13</compatibility>

<usage>

    <p>Le MPM event g&egrave;re certaines connexions de mani&egrave;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 (la plupart

    du temps pour les connexions SSL), 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&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éthodes : tout d'abord, il limite le nombre de connexions

    simultanées par thread en fonction du nombre de processus

    inactifs. Ensuite, 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.</p>

    <p>Cette directive permet de personnaliser finement la limite du

    nombre de connexions par thread. Un processus n'acceptera de

    nouvelles connexions que si le nombre actuel de connexions est

    inf&eacute;rieur &agrave; :</p>

    <p class="indent"><strong>

        <directive module="mpm_common">ThreadsPerChild</directive> +

        (<directive>AsyncRequestWorkerFactor</directive> *

        <var>nombre de threads inactifs</var>)

    </strong></p>

    <p>En d'autres termes, le nombre maximum de connexions simultan&eacute;es

    sera :</p>

    <p class="indent"><strong>

        (<directive>AsyncRequestWorkerFactor</directive> + 1) *

        <directive module="mpm_common">MaxRequestWorkers</directive>

    </strong></p>

    <p>La directive <directive

    module="mpm_common">MaxRequestWorkers</directive> se nommait

    <directive>MaxClients</directive> 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 <directive>AsyncRequestWorkerFactor</directive>

    accepte des valeurs d'argument de type non entier, comme "1.5".</p>

</usage>

</directivesynopsis>

</modulesynopsis>