event.xml.fr revision 576c49cd335618ad4b5351bd1c5f2cfd7584dba4
<?xml version="1.0"?>
<!-- English Revision : 926432 -->
<!-- French translation : Lucien GENTIS -->
<!-- Reviewed by : Vincent Deffontaines -->
<!--
Licensed to the Apache Software Foundation (ASF) under one or more
contributor license agreements. See the NOTICE file distributed with
this work for additional information regarding copyright ownership.
The ASF licenses this file to You under the Apache License, Version 2.0
(the "License"); you may not use this file except in compliance with
the License. You may obtain a copy of the License at
Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.
-->
<modulesynopsis metafile="event.xml.meta">
<name>event</name>
<description>Une variante du MPM <module>worker</module> conçue pour ne
mobiliser des threads que pour les connexions en cours de traitement</description>
<status>MPM</status>
<identifier>mpm_event_module</identifier>
<summary>
<p>Le module multi-processus (MPM) <module>event</module> est conçu
pour permettre le traitement d'un nombre accru de requêtes
simultanées en déléguant certaines tâches à des threads de support,
libérant par là-même le thread principal et lui permettant de
traiter les nouvelles requêtes. Il s'inspire du MPM
<module>worker</module> qui implémente un serveur hybride
multi-processus/multi-threads. Les directives de configuration à
l'exécution sont identiques à celles du MPM
<module>worker</module>.</p>
<p>Pour utiliser le MPM <module>event</module>, ajoutez
<code>--with-mpm=event</code> aux arguments du script
<program>configure</program> lorsque vous compilez le programme
<program>httpd</program>.</p>
</summary>
<section id="how-it-works"><title>Comment tout cela fonctionne</title>
<p>Ce MPM essaie de résoudre le 'problème keep alive' de HTTP.
Lorsqu'un client a soumis une première requête, il peut garder la
connexion ouverte, et envoyer les requêtes suivantes en utilisant le
même socket. Ceci permet de réduire de manière significative la
surcharge due à la création de connexions TCP.
Cependant, le serveur HTTP Apache
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>
<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.
Ceci permet au MPM d'éviter un verrouillage de haut niveau excessif,
ou de devoir activer le thread en écoute afin de lui envoyer un
socket keep alive. Tout ceci n'est actuellement compatible qu'avec
KQueue et EPoll.</p>
</section>
<section id="requirements"><title>Prérequis</title>
<p>Ce MPM dépend des opérations atomiques compare-and-swap
d'<glossary>APR</glossary> 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 <program>configure</program>. 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
<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>
</section>
<directivesynopsis location="mpm_common"><name>CoreDumpDirectory</name>
</directivesynopsis>
<directivesynopsis location="mpm_common"><name>EnableExceptionHook</name>
</directivesynopsis>
<directivesynopsis location="mpm_common"><name>Group</name>
</directivesynopsis>
<directivesynopsis location="mpm_common"><name>Listen</name>
</directivesynopsis>
<directivesynopsis location="mpm_common"><name>ListenBacklog</name>
</directivesynopsis>
<directivesynopsis location="mpm_common"><name>SendBufferSize</name>
</directivesynopsis>
<directivesynopsis location="mpm_common"><name>MaxClients</name>
</directivesynopsis>
<directivesynopsis location="mpm_common"><name>MaxMemFree</name>
</directivesynopsis>
<directivesynopsis location="mpm_common"><name>MaxRequestsPerChild</name>
</directivesynopsis>
<directivesynopsis location="mpm_common"><name>MaxSpareThreads</name>
</directivesynopsis>
<directivesynopsis location="mpm_common"><name>MinSpareThreads</name>
</directivesynopsis>
<directivesynopsis location="mpm_common"><name>PidFile</name>
</directivesynopsis>
<directivesynopsis location="mpm_common"><name>ScoreBoardFile</name>
</directivesynopsis>
<directivesynopsis location="mpm_common"><name>ServerLimit</name>
</directivesynopsis>
<directivesynopsis location="mpm_common"><name>StartServers</name>
</directivesynopsis>
<directivesynopsis location="mpm_common"><name>ThreadLimit</name>
</directivesynopsis>
<directivesynopsis location="mpm_common"><name>ThreadsPerChild</name>
</directivesynopsis>
<directivesynopsis location="mpm_common"><name>ThreadStackSize</name>
</directivesynopsis>
<directivesynopsis location="mpm_common"><name>User</name>
</directivesynopsis>
</modulesynopsis>