XML update.

<?xml version="1.0" encoding="UTF-8"?>

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

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

<!-- English Revision: 1742029:1772512 (outdated) -->

<!-- English Revision: 1772512 -->

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

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

    </section>

    <section id="graceful-close"><title>Arrêt de processus en douceur et

    utilisation du scoreboard</title>

        <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 <directive

	module="mpm_common">MaxRequestWorkers</directive> permet de limiter le

	nombre de requêtes pouvant être servies simultanément à un moment donné

	ainsi que le nombre de processus autorisés (<directive

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

	module="mpm_common">ThreadsPerChild</directive>), 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 à <directive

	module="mpm_common">MaxRequestWorkers</directive>, 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 <directive

	module="mpm_common">ListenBacklog</directive>). 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

	    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.

            </li>

            <li>Lorsque la charge du serveur diminue suffisamment pour que httpd

	    commence à stopper certains processus (par exemple pour respecter la

	    valeur de la directive <directive

	    module="mpm_common">MaxSpareThreads</directive>). Cette situation

	    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

	    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>

        <ul>

            <li>Utilisation de toutes les entrées du scoreboard dans la limite

	    de la valeur définie par <directive

	    module="mpm_common">ServerLimit</directive>. Les directives

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

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

	    permettent de limiter le nombre de processus actifs, alors que la

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

	    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 <directive

	    module="mpm_common">ServerLimit</directive> 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

	    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

	    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>

        </ul>

        <p>Le comportement décrit dans le dernier point est bien visible via

	<module>mod_status</module> 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>

    </section>

    <section id="limitations"><title>Limitations</title>

        <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