diff options
Diffstat (limited to 'docs/manual/mod/event.html.fr')
| -rw-r--r-- | docs/manual/mod/event.html.fr | 432 |
1 files changed, 216 insertions, 216 deletions
diff --git a/docs/manual/mod/event.html.fr b/docs/manual/mod/event.html.fr index ee188ce746..e94eaa222d 100644 --- a/docs/manual/mod/event.html.fr +++ b/docs/manual/mod/event.html.fr @@ -27,22 +27,22 @@ <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"> en </a> | -<a href="../es/mod/event.html" hreflang="es" rel="alternate" title="Español"> es </a> | -<a href="../fr/mod/event.html" title="Français"> fr </a></p> +<a href="../es/mod/event.html" hreflang="es" rel="alternate" title="Español"> es </a> | +<a href="../fr/mod/event.html" title="Français"> fr </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çue pour ne +<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ç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 de Module:</a></th><td>mpm_event_module</td></tr> -<tr><th><a href="module-dict.html#SourceFile">Fichier Source:</a></th><td>event.c</td></tr></table> +<tr><th><a href="module-dict.html#ModuleIdentifier">Identificateur de Module:</a></th><td>mpm_event_module</td></tr> +<tr><th><a href="module-dict.html#SourceFile">Fichier 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émentation asynchrone basée sur les évènements et conçu - pour permettre le traitement d'un nombre accru de requêtes - simultanées en déléguant certaines tâches - aux threads d'écoute, libérant par là-même les - threads de travail et leur permettant de traiter les nouvelles requêtes.</p> + l'indique, une implémentation asynchrone basée sur les évènements et conçu + pour permettre le traitement d'un nombre accru de requêtes + simultanées en déléguant certaines tâches + aux threads d'écoute, libérant par là-même les + threads de travail et leur permettant de traiter les nouvelles requê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 @@ -54,7 +54,7 @@ mobiliser des threads que pour les connexions en cours de traitement</td></tr> <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érequis</a></li> +<li><img alt="" src="../images/down.gif" /> <a href="#requirements">Pré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> @@ -78,7 +78,7 @@ mobiliser des threads que pour les connexions en cours de traitement</td></tr> <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__&list_id=144532&product=Apache%20httpd-2&query_format=specific&order=changeddate%20DESC%2Cpriority%2Cbug_severity&component=mpm_event">Problèmes connus</a></li><li><a href="https://bz.apache.org/bugzilla/enter_bug.cgi?product=Apache%20httpd-2&component=mpm_event">Signaler un bug</a></li></ul><h3>Voir aussi</h3> +<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__&list_id=144532&product=Apache%20httpd-2&query_format=specific&order=changeddate%20DESC%2Cpriority%2Cbug_severity&component=mpm_event">Problèmes connus</a></li><li><a href="https://bz.apache.org/bugzilla/enter_bug.cgi?product=Apache%20httpd-2&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> @@ -86,14 +86,14 @@ mobiliser des threads que pour les connexions en cours de traitement</td></tr> <div class="section"> <h2><a name="event-worker-relationship" id="event-worker-relationship">Relations avec le MPM Worker</a><a title="Lien permanent" href="#event-worker-relationship" class="permalink">¶</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émente un serveur hybride multi-processus et multi-threads. Un processus de -contrôle unique (le parent) est chargé de lancer des processus enfants. Chaque -processus enfant crée un nombre de threads serveurs défini via la directive +implémente un serveur hybride multi-processus et multi-threads. Un processus de +contrôle unique (le parent) est chargé de lancer des processus enfants. Chaque +processus enfant cré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'écoute qui surveille les requêtes entrantes et les distribue aux threads de -travail pour traitement au fur et à mesure de leur arrivée.</p> +d'écoute qui surveille les requêtes entrantes et les distribue aux threads de +travail pour traitement au fur et à mesure de leur arrivée.</p> -<p>Les directives de configuration à l'exécution sont identiques à celles que +<p>Les directives de configuration à l'exécution sont identiques à 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> @@ -101,234 +101,234 @@ propose le MPM <code class="module"><a href="../mod/worker.html">worker</a></cod <div class="section"> <h2><a name="how-it-works" id="how-it-works">Comment tout cela fonctionne</a><a title="Lien permanent" href="#how-it-works" class="permalink">¶</a></h2> - <p>Ce module MPM a été conçu à l'origine pour résoudre le "problème keep - alive" de HTTP. Lorsqu'un client a effectué une première requête, il peut - garder la connexion ouverte et envoyer les requêtes suivante en utilisant le - même socket, ce qui diminue considérablement la charge qui aurait été - induite par la cré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ées en provenance du client, ce qui - présente certains inconvénients. Pour résoudre ce problème, le MPM Event - utilise un thread d'écoute dédié pour chaque processus associé à un jeu de - threads de travail, partageant les files d'attentes spécifiques aux - requêtes en mode keep-alive (ou plus simplement en mode "lisible"), à celles - en mode écriture des résultats, et à celles en court de fermeture - ("closing"). Une boucle d'attente d'évènements déclenchée en fonction du - statut de la disponibilité du socket ajuste ces files d'attente et distribue + <p>Ce module MPM a été conçu à l'origine pour résoudre le "problème keep + alive" de HTTP. Lorsqu'un client a effectué une première requête, il peut + garder la connexion ouverte et envoyer les requêtes suivante en utilisant le + même socket, ce qui diminue considérablement la charge qui aurait été + induite par la cré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ées en provenance du client, ce qui + présente certains inconvénients. Pour résoudre ce problème, le MPM Event + utilise un thread d'écoute dédié pour chaque processus associé à un jeu de + threads de travail, partageant les files d'attentes spécifiques aux + requêtes en mode keep-alive (ou plus simplement en mode "lisible"), à celles + en mode écriture des résultats, et à celles en court de fermeture + ("closing"). Une boucle d'attente d'évènements déclenchée en fonction du + statut de la disponibilité 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és des noyaux modernes mis en valeur par + les fonctionnalité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 - éviter le problème de "thundering herd".</p> + éviter le problè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> + 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écédents, les connexions asynchrones nécessitaient - un thread de travail dédié, mais ce n'est plus le cas avec le MPM Event. - La page d'état de <code class="module"><a href="../mod/mod_status.html">mod_status</a></code> montre de nouvelles + <p>Avec les MPM précédents, les connexions asynchrones nécessitaient + un thread de travail dédié, mais ce n'est plus le cas avec le MPM Event. + La page d'é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'écriture TCP soit plein si la connexion est trop lente. Si + <dd>Lors de l'envoi de la réponse au client, il peut arriver que le + tampon d'é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éral <code>EWOULDBLOCK</code> ou <code>EAGAIN</code> - pour que l'on puisse y écrire à nouveau après un certain temps - d'inactivité. Le thread de travail qui utilise le socket doit alors - être en mesure de récupérer la tâche en attente et la restituer au - thread d'écoute qui, à son tour, la réattribuera au premier thread - de travail disponible, lorsqu'un évènement sera généré pour le socket - (par exemple, "il est maintenant possible d'écrire dans le socket"). - Veuillez vous reporter à la section à propos des limitations pour - plus de détails. + renvoie en général <code>EWOULDBLOCK</code> ou <code>EAGAIN</code> + pour que l'on puisse y écrire à nouveau après un certain temps + d'inactivité. Le thread de travail qui utilise le socket doit alors + être en mesure de récupérer la tâche en attente et la restituer au + thread d'écoute qui, à son tour, la réattribuera au premier thread + de travail disponible, lorsqu'un évènement sera généré pour le socket + (par exemple, "il est maintenant possible d'écrire dans le socket"). + Veuillez vous reporter à la section à propos des limitations pour + plus de détails. </dd> <dt>Keep-alive</dt> <dd>La gestion des connexions persistantes constitue la principale - amélioration par rapport au MPM Worker. Lorsqu'un thread de travail - a terminé l'envoi d'une réponse à un client, il peut restituer la - gestion du socket au thread d'écoute, qui à son tour va attendre un - évènement en provenance du système d'exploitation comme "le socket - est lisible". Si une nouvelle requête arrive en provenance du - client, le thread d'é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é par le thread d'écoute. Les threads de travail n'ont - donc plus à s'occuper des sockets inactifs et ils peuvent être - réutilisés pour traiter d'autres requêtes.</dd> + amélioration par rapport au MPM Worker. Lorsqu'un thread de travail + a terminé l'envoi d'une réponse à un client, il peut restituer la + gestion du socket au thread d'écoute, qui à son tour va attendre un + évènement en provenance du système d'exploitation comme "le socket + est lisible". Si une nouvelle requête arrive en provenance du + client, le thread d'é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é par le thread d'écoute. Les threads de travail n'ont + donc plus à s'occuper des sockets inactifs et ils peuvent être + réutilisés pour traiter d'autres requêtes.</dd> <dt>Closing</dt> <dd>Parfois, le MPM doit effectuer une fermeture progressive, c'est - à dire envoyer au client une erreur survenue précédemment alors que - ce dernier est en train de transmettre des données à httpd. Envoyer la réponse et - fermer immédiatement la connexion n'est pas une bonne solution car - le client (qui est encore en train d'envoyer le reste de la requête) - verrait sa connexion réinitialisée et ne pourrait pas lire la - réponse de httpd. - La fermeture progressive est limitée dans le temps, - mais elle peut tout de même être assez longue, si bien qu'elle est - confiée à un thread de travail (y compris les procédures d'arrêt et + à dire envoyer au client une erreur survenue précédemment alors que + ce dernier est en train de transmettre des données à httpd. Envoyer la réponse et + fermer immédiatement la connexion n'est pas une bonne solution car + le client (qui est encore en train d'envoyer le reste de la requête) + verrait sa connexion réinitialisée et ne pourrait pas lire la + réponse de httpd. + La fermeture progressive est limitée dans le temps, + mais elle peut tout de même être assez longue, si bien qu'elle est + confiée à un thread de travail (y compris les procédures d'arrê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épasser - leur délai d'attente (le thread d'écoute ne gère jamais les - connexions, si ce n'est attendre et dispatcher les évènements - qu'elles génèrent).</dd> + c'est aussi le cas lorsque des connexions finissent par dépasser + leur délai d'attente (le thread d'écoute ne gère jamais les + connexions, si ce n'est attendre et dispatcher les évènements + qu'elles génèrent).</dd> </dl> - <p>Ces améliorations sont disponible pour les connexions HTTP ou HTTPS.</p> + <p>Ces améliorations sont disponible pour les connexions HTTP ou HTTPS.</p> - <p>Les états de connexions ci-dessus sont gérés par le thread d'écoute - via des files d'attente dédiées qui, jusqu'à la version 2.4.27, étaient - lues toutes les 100ms pour déterminer quelles connexions avaient atteint - des limites de duré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'était une solution simple - et efficace mais qui présentait un inconvénient : ces lectures - régulières forçaient le thread d'écoute à se réveiller, souvent sans - nécessité (alors qu'il était totalement inactif), ce qui consommait des + <p>Les états de connexions ci-dessus sont gérés par le thread d'écoute + via des files d'attente dédiées qui, jusqu'à la version 2.4.27, étaient + lues toutes les 100ms pour déterminer quelles connexions avaient atteint + des limites de duré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'était une solution simple + et efficace mais qui présentait un inconvénient : ces lectures + régulières forçaient le thread d'écoute à se réveiller, souvent sans + nécessité (alors qu'il était totalement inactif), ce qui consommait des ressources pour rien. A partir de la version 2.4.28, ces files d'attente - sont entièrement gérées selon une logique basées sur les évènements, et - ne font donc plus l'objet d'une lecture systématique. Les environnements - aux ressources limitées, comme les serveurs embarqués, seront les plus - grands bénéficiaires de cette amélioration.</p> + sont entièrement gérées selon une logique basées sur les évènements, et + ne font donc plus l'objet d'une lecture systématique. Les environnements + aux ressources limitées, comme les serveurs embarqués, seront les plus + grands bénéficiaires de cette amélioration.</p> - <h3><a name="graceful-close" id="graceful-close">Arrêt de processus en douceur et + <h3><a name="graceful-close" id="graceful-close">Arrêt de processus en douceur et utilisation du scoreboard</a></h3> - <p>Ce MPM présentait dans le passé des limitations de montée en + <p>Ce MPM présentait dans le passé des limitations de monté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êtes pouvant être servies simultanément à un moment donné - ainsi que le nombre de processus autorisé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ésente l'ensemble des processus en cours d'exécution et - l'état de leurs threads de travail. Si le scoreboard est plein - (autrement dit si aucun des threads n'est dans un état inactif) et si le - nombre de requêtes actives servies est inférieur à <code class="directive"><a href="../mod/mpm_common.html#maxrequestworkers">MaxRequestWorkers</a></code>, cela signifie que - certains d'entre eux bloquent les nouvelles requêtes qui pourraient être + nombre de requêtes pouvant être servies simultanément à un moment donné + ainsi que le nombre de processus autorisé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ésente l'ensemble des processus en cours d'exécution et + l'état de leurs threads de travail. Si le scoreboard est plein + (autrement dit si aucun des threads n'est dans un état inactif) et si le + nombre de requêtes actives servies est inférieur à <code class="directive"><a href="../mod/mpm_common.html#maxrequestworkers">MaxRequestWorkers</a></code>, cela signifie que + certains d'entre eux bloquent les nouvelles requêtes qui pourraient être servies et sont en l'occurrence mises en attente (dans la limite de la - valeur imposé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és dans un état d'arrêt en douceur car ils attendent - de terminer leur travail sur une connexion TCP pour s'arrêter et ainsi libérer - une entrée dans le scoreboard (par exemple dans le cas du traitement des - requêtes de longue durée, des clients lents ou des connexions en - keep-alive). Voici deux scénarios courants :</p> + valeur imposé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és dans un état d'arrêt en douceur car ils attendent + de terminer leur travail sur une connexion TCP pour s'arrêter et ainsi libérer + une entrée dans le scoreboard (par exemple dans le cas du traitement des + requêtes de longue durée, des clients lents ou des connexions en + keep-alive). Voici deux scénarios courants :</p> <ul> <li>Pendant un <a href="../stopping.html#graceful">graceful - restart</a>. Le processus parent demande à tous ses processus - enfants de terminer leur travail et de s'arrêter pendant qu'il + restart</a>. Le processus parent demande à tous ses processus + enfants de terminer leur travail et de s'arrêter pendant qu'il recharge la configuration et lance de nouveaux processus. Si les - processus existants continuent de s'exécuter pendant un certain - temps avant de s'arrêter, le scoreboard sera partiellement occupé - jusqu'à ce que les entrées correspondantes soient libérées. + processus existants continuent de s'exécuter pendant un certain + temps avant de s'arrêter, le scoreboard sera partiellement occupé + jusqu'à ce que les entrées correspondantes soient libérées. </li> <li>Lorsque la charge du serveur diminue suffisamment pour que httpd - commence à stopper certains processus (par exemple pour respecter la + commence à 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èmatique car lorsque la charge augmente à nouveau, httpd va + est problèmatique car lorsque la charge augmente à nouveau, httpd va essayer de lancer de nouveaux processus. Si cette situation se - répète, le nombre de processus peut augmenter sensiblement, - aboutissant à un mélange d'anciens processus tentant de s'arrêter et + répète, le nombre de processus peut augmenter sensiblement, + aboutissant à un mélange d'anciens processus tentant de s'arrê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êts graceful de manière plus efficace. Voici certaines de - ces améliorations :</p> + traiter les arrêts graceful de manière plus efficace. Voici certaines de + ces améliorations :</p> <ul> - <li>Utilisation de toutes les entré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 + <li>Utilisation de toutes les entré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êt graceful pour - permettre l'utilisation d'entrées supplémentaires du scoreboard en - cas de besoin. L'idée consiste à utiliser <code class="directive"><a href="../mod/mpm_common.html#serverlimit">ServerLimit</a></code> pour indiquer à httpd - conbien de processus supplémentaires seront tolérés avant - d'atteindre les limites imposées par les ressources du système. + prend aussi en compte les proccessus en arrêt graceful pour + permettre l'utilisation d'entrées supplémentaires du scoreboard en + cas de besoin. L'idée consiste à utiliser <code class="directive"><a href="../mod/mpm_common.html#serverlimit">ServerLimit</a></code> pour indiquer à httpd + conbien de processus supplémentaires seront tolérés avant + d'atteindre les limites imposées par les ressources du système. </li> - <li>Les processus en arrêt graceful doivent fermer leurs connexions + <li>Les processus en arrêt graceful doivent fermer leurs connexions en keep-alive.</li> - <li>Lors d'un arrêt graceful, s'il y a plus de threads de travail en - cours d'exécution que de connexions ouvertes pour un processus - donné, ces threads sont arrêtés afin de libérer les ressources plus - vite (ce qui peut s'avérer nécessaire pour lancer de nouveaux + <li>Lors d'un arrêt graceful, s'il y a plus de threads de travail en + cours d'exécution que de connexions ouvertes pour un processus + donné, ces threads sont arrêtés afin de libérer les ressources plus + vite (ce qui peut s'avérer nécessaire pour lancer de nouveaux processus).</li> - <li>Si le scoreboard est plein, empêche d'arrêter d'autres processus - en mode graceful afin de réduire la charge jusqu'à ce que tous les - anciens processus soient arrêtés (sinon la situation empirerait lors - d'une remontée en charge).</li> + <li>Si le scoreboard est plein, empêche d'arrêter d'autres processus + en mode graceful afin de réduire la charge jusqu'à ce que tous les + anciens processus soient arrêtés (sinon la situation empirerait lors + d'une remontée en charge).</li> </ul> - <p>Le comportement décrit dans le dernier point est bien visible via + <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ère indique le PID et - la seconde si le processus est en cours d'arrêt ou non ; l'état - supplémentaire "Yes (old gen)" indique un processus encore en exécution - après un redémarrage graceful.</p> + nouvelles colonnes "Slot" et "Stopping". La première indique le PID et + la seconde si le processus est en cours d'arrêt ou non ; l'état + supplémentaire "Yes (old gen)" indique un processus encore en exécution + après un redémarrage graceful.</p> <h3><a name="limitations" id="limitations">Limitations</a></h3> - <p>La gestion améliorée des connexions peut ne pas fonctionner pour - certains filtres de connexion qui se sont déclaré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 + <p>La gestion améliorée des connexions peut ne pas fonctionner pour + certains filtres de connexion qui se sont déclaré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ît lorsqu'une requête utilise un - filtre en sortie qui doit pouvoir lire et/ou modifier la totalité du - corps de la réponse. Si la connexion avec le client se bloque pendant - que le filtre traite les données, et si la quantité de données produites - par le filtre est trop importante pour être stockée en mémoire, le - thread utilisé pour la requête n'est pas libéré pendant que httpd attend - que les données soient transmises au client.<br /> + <p>Une restriction similaire apparaît lorsqu'une requête utilise un + filtre en sortie qui doit pouvoir lire et/ou modifier la totalité du + corps de la réponse. Si la connexion avec le client se bloque pendant + que le filtre traite les données, et si la quantité de données produites + par le filtre est trop importante pour être stockée en mémoire, le + thread utilisé pour la requête n'est pas libéré pendant que httpd attend + que les donné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é. La première situation est prévisible ; en effet, le MPM Event a - une parfaite visibilité sur la fin du contenu, et il peut utiliser les - évènements : le thread de travail qui sert la réponse peut envoyer les - premiers octets jusqu'à ce que <code>EWOULDBLOCK</code> ou - <code>EAGAIN</code> soit renvoyé, et déléguer le reste de la réponse au thread - d'écoute. Ce dernier en retour attend un évènement sur le socket, et - délègue le reste de la réponse au premier - thread de travail disponible. Dans la deuxième situation par contre - (FCGI/CGI/contenu mandaté), le MPM n'a pas de visibilité sur la fin de - la réponse, et le thread de travail doit terminer sa tâche avant de - rendre le contrôle au thread d'écoute. La seule solution consisterait - alors à stocker la réponse en mémoire, mais ce ne serait pas l'option la - plus sure en matière de stabilité du serveur et d'empreinte mémoire. + mandaté. La première situation est prévisible ; en effet, le MPM Event a + une parfaite visibilité sur la fin du contenu, et il peut utiliser les + évènements : le thread de travail qui sert la réponse peut envoyer les + premiers octets jusqu'à ce que <code>EWOULDBLOCK</code> ou + <code>EAGAIN</code> soit renvoyé, et déléguer le reste de la réponse au thread + d'écoute. Ce dernier en retour attend un évènement sur le socket, et + délègue le reste de la réponse au premier + thread de travail disponible. Dans la deuxième situation par contre + (FCGI/CGI/contenu mandaté), le MPM n'a pas de visibilité sur la fin de + la réponse, et le thread de travail doit terminer sa tâche avant de + rendre le contrôle au thread d'écoute. La seule solution consisterait + alors à stocker la réponse en mémoire, mais ce ne serait pas l'option la + plus sure en matière de stabilité du serveur et d'empreinte mémoire. </p> - <h3><a name="background" id="background">Matériel d'arrière-plan</a></h3> - <p>Le modèle event a été rendu possible par l'introduction de nouvelles - APIs dans les systèmes d'exploitation supportés :</p> + <h3><a name="background" id="background">Matériel d'arrière-plan</a></h3> + <p>Le modèle event a été rendu possible par l'introduction de nouvelles + APIs dans les systèmes d'exploitation supportés :</p> <ul> <li>epoll (Linux) </li> <li>kqueue (BSD) </li> <li>event ports (Solaris) </li> </ul> - <p>Avant que ces APIs soient mises à disposition, les APIs - traditionnelles <code>select</code> et <code>poll</code> devaient être - utilisées. Ces APIs deviennent lentes si on les utilise pour gérer de - nombreuses connexions ou si le jeu de connexions possède un taux de - renouvellement élevé. Les nouvelles APIs permettent de gérer beaucoup + <p>Avant que ces APIs soient mises à disposition, les APIs + traditionnelles <code>select</code> et <code>poll</code> devaient être + utilisées. Ces APIs deviennent lentes si on les utilise pour gérer de + nombreuses connexions ou si le jeu de connexions possède un taux de + renouvellement élevé. Les nouvelles APIs permettent de gérer beaucoup plus de connexions et leur performances sont meilleures lorsque le jeu - de connexions à gérer change fréquemment. Ces APIs ont donc rendu - possible l'écriture le MPM Event qui est mieux adapté à la situation - HTTP typique où de nombreuses connexions sont inactives.</p> + de connexions à gérer change fréquemment. Ces APIs ont donc rendu + possible l'écriture le MPM Event qui est mieux adapté à la situation + HTTP typique où de nombreuses connexions sont inactives.</p> - <p>Le MPM Event suppose que l'implémentation de <code>apr_pollset</code> + <p>Le MPM Event suppose que l'implémentation de <code>apr_pollset</code> sous-jacente est raisonnablement sure avec l'utilisation des threads - (threadsafe). Ceci évite au MPM de devoir effectuer trop verrouillages - de haut niveau, ou d'avoir à réveiller le thread d'écoute pour lui + (threadsafe). Ceci évite au MPM de devoir effectuer trop verrouillages + de haut niveau, ou d'avoir à réveiller le thread d'écoute pour lui envoyer un socket keep-alive. Ceci n'est possible qu'avec KQueue et EPoll.</p> @@ -336,35 +336,35 @@ propose le MPM <code class="module"><a href="../mod/worker.html">worker</a></cod </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érequis</a><a title="Lien permanent" href="#requirements" class="permalink">¶</a></h2> - <p>Ce MPM dépend des opérations atomiques compare-and-swap +<h2><a name="requirements" id="requirements">Prérequis</a><a title="Lien permanent" href="#requirements" class="permalink">¶</a></h2> + <p>Ce MPM dépend des opé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 à APR - d'implémenter les opérations atomiques en utilisant des instructions + script <code class="program"><a href="../programs/configure.html">configure</a></code>. 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 + <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 + 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 <code>libkse</code> (voir <code>man libmap.conf</code>).</li> <li>Pour NetBSD, il est recommander d'utiliser la version 2.0 ou - supérieure.</li> + 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 + <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> @@ -372,40 +372,40 @@ propose le MPM <code class="module"><a href="../mod/worker.html">worker</a></cod <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><a title="Lien permanent" href="#asyncrequestworkerfactor" class="permalink">¶</a></h2> <table class="directive"> -<tr><th><a href="directive-dict.html#Description">Description:</a></th><td>Limite le nombre de connexions simultanées par thread</td></tr> +<tr><th><a href="directive-dict.html#Description">Description:</a></th><td>Limite le nombre de connexions simultané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#Default">Dé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é:</a></th><td>Disponible depuis la version 2.3.13</td></tr> +<tr><th><a href="directive-dict.html#Compatibility">Compatibilité:</a></th><td>Disponible depuis la version 2.3.13</td></tr> </table> - <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, 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 :</p> + <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, 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 :</p> <ul> <li>il limite le nombre de connexions - simultanées par thread en fonction du nombre de processus + simultanées par thread en fonction du nombre de processus inactifs;</li> - <li>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.</li> + <li>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.</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 à l'état "closing") est - inférieur à :</p> + compter les connexions à l'état "closing") est + inférieur à :</p> <p class="indent"><strong> <code class="directive"><a href="../mod/mpm_common.html#threadsperchild">ThreadsPerChild</a></code> + @@ -414,7 +414,7 @@ propose le MPM <code class="module"><a href="../mod/worker.html">worker</a></cod </strong></p> <p>Il est possible d'effectuer une estimation du nombre maximum de - connexions simultanées pour tous les processus et pour un nombre donné moyen + connexions simultanées pour tous les processus et pour un nombre donné moyen de threads de travail inactifs comme suit : </p> @@ -440,7 +440,7 @@ max_connections = (ThreadsPerChild + (AsyncRequestWorkerFactor * idle_workers)) </div> <p>Lorsque tous les threads de travail sont inactifs, le nombre maximum - absolu de connexions simultanées peut être calculé de manière plus simple :</p> + absolu de connexions simultanées peut être calculé de manière plus simple :</p> <p class="indent"><strong> (<code class="directive">AsyncRequestWorkerFactor</code> + 1) * @@ -459,8 +459,8 @@ AsyncRequestWorkerFactor = 2</pre> <pre class="prettyprint lang-config">idle_workers = 10</pre> - <p>Nous pouvons calculer le nombre maximum absolu de connexions simultanées - de deux manières :</p> + <p>Nous pouvons calculer le nombre maximum absolu de connexions simultanées + de deux manières :</p> <pre class="prettyprint lang-config">max_connections = (ThreadsPerChild + (AsyncRequestWorkerFactor * idle_workers)) * ServerLimit = (10 + (2 * 10)) * 4 = 120 @@ -470,16 +470,16 @@ max_connections = (AsyncRequestWorkerFactor + 1) * MaxRequestWorkers </div> - <p>Le réglage de la directive - <code class="directive">AsyncRequestWorkerFactor</code> nécessite de connaître le - trafic géré par httpd pour chaque style d'utilisation spécifique ; si vous - modifiez la valeur par défaut, vous devrez par conséquent effectuer des - tests approfondis en vous appuyant étroitement sur les données fournies par + <p>Le réglage de la directive + <code class="directive">AsyncRequestWorkerFactor</code> nécessite de connaître le + trafic géré par httpd pour chaque style d'utilisation spécifique ; si vous + modifiez la valeur par défaut, vous devrez par conséquent effectuer des + tests approfondis en vous appuyant étroitement sur les donné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 à sa + ci-dessus montre que cet ancien nom ne correspondait pas à sa signification exacte pour le MPM event.</p> <p>La directive <code class="directive">AsyncRequestWorkerFactor</code> @@ -490,8 +490,8 @@ max_connections = (AsyncRequestWorkerFactor + 1) * MaxRequestWorkers </div> <div class="bottomlang"> <p><span>Langues Disponibles: </span><a href="../en/mod/event.html" hreflang="en" rel="alternate" title="English"> en </a> | -<a href="../es/mod/event.html" hreflang="es" rel="alternate" title="Español"> es </a> | -<a href="../fr/mod/event.html" title="Français"> fr </a></p> +<a href="../es/mod/event.html" hreflang="es" rel="alternate" title="Español"> es </a> | +<a href="../fr/mod/event.html" title="Français"> fr </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&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'; @@ -510,7 +510,7 @@ var comments_identifier = 'http://httpd.apache.org/docs/trunk/mod/event.html'; } })(window, document); //--><!]]></script></div><div id="footer"> -<p class="apache">Copyright 2018 The Apache Software Foundation.<br />Autorisé sous <a href="http://www.apache.org/licenses/LICENSE-2.0">Apache License, Version 2.0</a>.</p> +<p class="apache">Copyright 2018 The Apache Software Foundation.<br />Autorisé 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(); |