<?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énients. Pour résoudre ce problème, <module>event</module>
- utilise un thread dédié qui gère non seulement les sockets en
- écoute, mais aussi tous les sockets en é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ées.</p>
+
+ <p>Le gestionnaire de connexion amélioré 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éserve un thread par connexion.</p>
<p>Le MPM présuppose que l'implé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é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è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 (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âches pour les connexions asynchrones établies.</p>
+
+ <p>Pour minimiser les effets de ce problè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érieur à :</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é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>
projects / apache / commitdiff