From: Lucien Gentis Date: Sat, 18 Jun 2016 14:03:17 +0000 (+0000) Subject: XML updates. X-Git-Tag: 2.4.22~6 X-Git-Url: https://granicus.if.org/sourcecode?a=commitdiff_plain;h=856b90cce6cb8e900a7cf5782fbb0bbd63f19621;p=apache XML updates. git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/branches/2.4.x@1749038 13f79535-47bb-0310-9956-ffa450edef68 --- diff --git a/docs/manual/mod/mod_ssl.xml.fr b/docs/manual/mod/mod_ssl.xml.fr index a7c581d37e..346defb2e5 100644 --- a/docs/manual/mod/mod_ssl.xml.fr +++ b/docs/manual/mod/mod_ssl.xml.fr @@ -1,7 +1,7 @@ - + @@ -1401,10 +1401,12 @@ SSLCARevocationFile SSLCARevocationCheck Active la vérification des révocations basée sur les CRL -SSLCARevocationCheck chain|leaf|none +SSLCARevocationCheck chain|leaf|none flags SSLCARevocationCheck none server config virtual host +Le drapeau optionnel flags est disponible à partir de la +version 2.5-dev du serveur HTTP Apache

@@ -1417,27 +1419,35 @@ recommandée), les vérifications CRL sont effectuées sur tous les certificats de la chaîne, alors que la valeur leaf limite la vérification au certificat hors chaîne (la feuille).

- -Lorsque la directive est définie à <code>chain</code> ou -<code>leaf</code>, les CRLs doivent être disponibles pour que la -validation réussisse +

flags peut prendre comme valeurs

+
    +
  • no_crl_for_cert_ok

    Avant la version 2.3.15, les vérifications CRL dans mod_ssl réussissaient même si aucune CRL n'était trouvée dans les chemins définis par les directives SSLCARevocationFile ou SSLCARevocationPath. Le comportement a -changé avec l'introduction de cette directive : lorsque la vérification -est activée, les CRLs doivent être présentes pour que la +module="mod_ssl">SSLCARevocationPath.

    +

    Le comportement a +changé avec l'introduction de la directive +SSLCARevocationFile : par défaut avec +chain ou leaf, les CRLs doivent être présentes pour que la validation réussisse ; dans le cas contraire, elle échouera avec une -erreur "CRL introuvable". -

    - +erreur "unable to get certificate CRL".

    +

    La valeur no_crl_for_cert_ok du drapeau flag permet de +retrouver le comportement précédent.

    +
    • +
Exemple SSLCARevocationCheck chain +Compatibilité avec la branche 2.2 + +SSLCARevocationCheck chain no_crl_for_cert_ok + + diff --git a/docs/manual/mod/mpm_common.xml.fr b/docs/manual/mod/mpm_common.xml.fr index b15f65bc3c..0dbc250ff3 100644 --- a/docs/manual/mod/mpm_common.xml.fr +++ b/docs/manual/mod/mpm_common.xml.fr @@ -1,7 +1,7 @@ - + - + @@ -25,76 +25,76 @@ mpm_common -Une série de directives implémentées par plusieurs +Une série de directives implémentées par plusieurs modules multi-processus (MPM) MPM CoreDumpDirectory -Le répertoire dans lequel le serveur HTTP Apache va tenter de se -positionner avant d'effectuer un vidage mémoire -CoreDumpDirectory répertoire -Voir ci-dessous pour le répertoire par défaut +Le répertoire dans lequel le serveur HTTP Apache va tenter de se +positionner avant d'effectuer un vidage mémoire +CoreDumpDirectory répertoire +Voir ci-dessous pour le répertoire par défaut server config eventworker prefork -

Cette directive permet de définir le répertoire dans lequel +

Cette directive permet de définir le répertoire dans lequel Apache httpd va tenter de se positionner avant d'effectuer un vidage - mémoire sur disque. - Si votre système d'exploitation est configuré pour créer des - fichiers de vidage mémoire dans le répertoire de travail des - processus qui se sont crashés, - CoreDumpDirectory est nécessaire pour - définir un répertoire de travail autre que le répertoire par défaut - ServerRoot, ce répertoire de - travail ne devant pas être accessible en écriture par l'utilisateur sous - lequel le serveur s'exécute.

- -

Si vous avez besoin d'un vidage mémoire pour le débogage, vous - pouvez utiliser cette directive pour le placer à un endroit - différent. Cette directive n'a aucun effet si votre système - d'exploitation n'est pas configuré pour créer des - fichiers de vidage mémoire dans le répertoire de travail des - processus qui se sont crashés.

- - Vidages mémoire sous Linux -

Si Apache httpd est démarré sous l'utilisateur root puis bascule vers - un autre utilisateur, le noyau Linux désactive les - vidages mémoire, même si le répertoire est accessible en écriture au - processus. Apache httpd (versions 2.0.46 et supérieures) réactive les - vidages mémoire sous Linux 2.4 et au delà, mais seulement si vous - définissez une directive CoreDumpDirectory.

+ mémoire sur disque. + Si votre système d'exploitation est configuré pour créer des + fichiers de vidage mémoire dans le répertoire de travail des + processus qui se sont crashés, + CoreDumpDirectory est nécessaire pour + définir un répertoire de travail autre que le répertoire par défaut + ServerRoot, ce répertoire de + travail ne devant pas être accessible en écriture par l'utilisateur sous + lequel le serveur s'exécute.

+ +

Si vous avez besoin d'un vidage mémoire pour le débogage, vous + pouvez utiliser cette directive pour le placer à un endroit + différent. Cette directive n'a aucun effet si votre système + d'exploitation n'est pas configuré pour créer des + fichiers de vidage mémoire dans le répertoire de travail des + processus qui se sont crashés.

+ + Vidages mémoire sous Linux +

Si Apache httpd est démarré sous l'utilisateur root puis bascule vers + un autre utilisateur, le noyau Linux désactive les + vidages mémoire, même si le répertoire est accessible en écriture au + processus. Apache httpd (versions 2.0.46 et supérieures) réactive les + vidages mémoire sous Linux 2.4 et au delà, mais seulement si vous + définissez une directive CoreDumpDirectory.

 - Vidages mémoire sous BSD -

Pour activer le vidage mémoire des exécutables suid sur les - systèmes de style BSD (comme FreeBSD), définissez - kern.sugid_coredump à 1. + Vidages mémoire sous BSD +

Pour activer le vidage mémoire des exécutables suid sur les + systèmes de style BSD (comme FreeBSD), définissez + kern.sugid_coredump à 1.

- Signaux spécifiques -

CoreDumpDirectory n'est traité qu'à la + Signaux spécifiques +

CoreDumpDirectory n'est traité qu'à la reception d'un certain nombre de signaux , SIGFPE, SIGILL, SIGABORT, SIGSEGV, et SIGBUS.

- Sur certains systèmes d'exploitation, SIGQUIT provoque aussi un - vidage mémoire, mais n'est pas traité par les directives + Sur certains systèmes d'exploitation, SIGQUIT provoque aussi un + vidage mémoire, mais n'est pas traité par les directives CoreDumpDirectory ou EnableExceptionHook, si bien que la - définition du répertoire d'enregistrement du vidage mémoire est - entièrement dévolue au système d'exploitation.

+ définition du répertoire d'enregistrement du vidage mémoire est + entièrement dévolue au système d'exploitation.

 EnableExceptionHook -Active un hook ("point d'accrochage logiciel") qui exécute des -gestionnaires d'exception après un crash +Active un hook ("point d'accrochage logiciel") qui exécute des +gestionnaires d'exception après un crash EnableExceptionHook On|Off EnableExceptionHook Off server config @@ -103,50 +103,50 @@ gestionnaires d'exception après un crash prefork -

Pour des raisons de sécurité, cette directive n'est disponible - que si la compilation du serveur a été configurée avec l'option +

Pour des raisons de sécurité, cette directive n'est disponible + que si la compilation du serveur a été configurée avec l'option --enable-exception-hook. Elle permet d'activer un hook ("point d'accrochage logiciel") - qui autorise certains modules externes à effectuer un branchement et - accomplir telle ou telle action après le crash d'un processus + qui autorise certains modules externes à effectuer un branchement et + accomplir telle ou telle action après le crash d'un processus enfant.

Deux modules, mod_whatkilledus et mod_backtrace utilisent ce hook. Veuillez vous - référer à la page EnableExceptionHook de Jeff Trawick pour plus - d'informations à leur sujet.

+ d'informations à leur sujet.

 GracefulShutdownTimeout -Spécifie le délai maximum après lequel le serveur va -s'arrêter dans le cas d'un arrêt "en douceur" +Spécifie le délai maximum après lequel le serveur va +s'arrêter dans le cas d'un arrêt "en douceur" GracefulShutdownTimeout seconds GracefulShutdownTimeout 0 server config eventworker prefork -Disponible dans les versions 2.2 et supérieures +Disponible dans les versions 2.2 et supérieures

La directive GracefulShutdownTimeout - permet de spécifier le temps, en secondes, pendant lequel le serveur - va continuer à fonctionner après avoir reçu un signal - "graceful-stop" ("Arrêt en douceur"), afin de terminer le traitement + permet de spécifier le temps, en secondes, pendant lequel le serveur + va continuer à fonctionner après avoir reçu un signal + "graceful-stop" ("Arrêt en douceur"), afin de terminer le traitement des connexions en cours.

-

Définir cette valeur à zéro signifie au serveur d'attendre - jusqu'à ce que toutes les requêtes en cours aient été traitées.

+

Définir cette valeur à zéro signifie au serveur d'attendre + jusqu'à ce que toutes les requêtes en cours aient été traitées.

 PidFile Ficher dans lequel le serveur enregistre l'identificateur -de processus du démon +de processus du démon PidFile nom fichier PidFile logs/httpd.pid server config @@ -156,11 +156,11 @@ de processus du démon -

La directive PidFile permet de définir le +

La directive PidFile permet de définir le ficher dans lequel le serveur - enregistre l'identificateur de processus du démon. Si le chemin du - fichier n'est pas absolu, il est considéré comme relatif au chemin - défini par la directive ServerRoot.

Exemple @@ -170,60 +170,60 @@ de processus du démon

Il est souvent utile de pouvoir envoyer un signal au - serveur afin qu'il ferme et ouvre à nouveau ses journaux + serveur afin qu'il ferme et ouvre à nouveau ses journaux d'erreur et de transfert, et recharge son fichier de configuration. Pour ce faire, on envoie un signal SIGHUP - (kill -1) à l'identificateur de processus enregistré dans le fichier - défini par la directive PidFile.

+ (kill -1) à l'identificateur de processus enregistré dans le fichier + défini par la directive PidFile.

La directive PidFile fait l'objet des - mêmes avertissements que ceux concernant le chemin d'enregistrement + mêmes avertissements que ceux concernant le chemin d'enregistrement des fichiers journaux et la sécurité.

+ href="../misc/security_tips.html#serverroot">sécurité.

Note

Depuis la version 2 du serveur HTTP Apache, nous recommandons de n'utiliser que le script apachectl, ou le script de - démarrage fourni avec votre système d'exploitation pour (re)démarrer ou - arrêter le serveur.

+ démarrage fourni avec votre système d'exploitation pour (re)démarrer ou + arrêter le serveur.

 Listen -Les adresses IP et ports sur lesquels le serveur écoute -Listen [adresse IP:]numéro port +Les adresses IP et ports sur lesquels le serveur écoute +Listen [adresse IP:]numéro port [protocole] server config eventworker preforkmpm_winnt mpm_netwarempmt_os2 -L'argument protocole est supporté depuis la version +L'argument protocole est supporté depuis la version 2.1.5 -

La directive Listen permet de signifier à - Apache httpd de ne se mettre à l'écoute que sur les adresses IP et ports spécifiés ; par - défaut, le serveur répond aux requêtes en provenance de toutes les - interfaces réseau. La directive Listen est - dorénavant requise, et si elle est absente du fichier de - configuration, le serveur refusera de démarrer. Ceci constitue un - changement par rapport aux versions précédentes d'Apache httpd.

+

La directive Listen permet de signifier à + Apache httpd de ne se mettre à l'écoute que sur les adresses IP et ports spécifiés ; par + défaut, le serveur répond aux requêtes en provenance de toutes les + interfaces réseau. La directive Listen est + dorénavant requise, et si elle est absente du fichier de + configuration, le serveur refusera de démarrer. Ceci constitue un + changement par rapport aux versions précédentes d'Apache httpd.

La directive Listen signifie au serveur de - n'accepter les requêtes entrantes que vers le port ou le couple - adresse-port spécifié. Si seulement un port est spécifié, le serveur - se met à l'écoute sur ce port sur toutes les interfaces réseau. Si une adresse IP - et un port sont spécifiés, le serveur va se mettre à l'écoute sur ce port sur - l'interface réseau correspondant à l'adresse IP.

+ n'accepter les requêtes entrantes que vers le port ou le couple + adresse-port spécifié. Si seulement un port est spécifié, le serveur + se met à l'écoute sur ce port sur toutes les interfaces réseau. Si une adresse IP + et un port sont spécifiés, le serveur va se mettre à l'écoute sur ce port sur + l'interface réseau correspondant à l'adresse IP.

On peut utiliser autant de directives - Listen que nécessaire pour spécifier - plusieurs adresses et/ou ports à écouter. Le serveur répondra aux - requêtes vers tous les adresses et ports spécifiés.

+ Listen que nécessaire pour spécifier + plusieurs adresses et/ou ports à écouter. Le serveur répondra aux + requêtes vers tous les adresses et ports spécifiés.

Par exemple, pour que le serveur accepte les connexions sur les ports 80 et 8000, utilisez :

@@ -234,30 +234,30 @@ Listen 8000

Pour que le serveur accepte les connexions sur deux interfaces et - ports particuliers, spécifiez :

+ ports particuliers, spécifiez :

Listen 192.170.2.1:80 Listen 192.170.2.5:8000 -

Les adressee IPv6 doivent être entourées de crochets, comme dans +

Les adressee IPv6 doivent être entourées de crochets, comme dans l'exemple suivant :

Listen [2001:db8::a00:20ff:fea7:ccea]:80 -

L'argument optionnel protocole n'est pas nécessaire +

L'argument optionnel protocole n'est pas nécessaire dans la plupart des configurations. S'il est absent, - https est la valeur par défaut pour le port 443 et + https est la valeur par défaut pour le port 443 et http l'est pour tous les autres ports. L'argument - protocole sert à déterminer quel module doit traiter une requête, et - à appliquer des optimisations spécifiques à certains protocoles à + protocole sert à déterminer quel module doit traiter une requête, et + à appliquer des optimisations spécifiques à certains protocoles à l'aide de la directive AcceptFilter.

-

La spécification d'un protocole n'est nécessaire que si vous +

La spécification d'un protocole n'est nécessaire que si vous utilisez des ports non standards. Par exemple, pour configurer un site en https sur le port 8443 :

@@ -266,63 +266,74 @@ Listen 192.170.2.5:8000 Condition d'erreur - Plusieurs directives Listen pour les mêmes + Plusieurs directives Listen pour les mêmes adresse IP/port vont provoquer l'envoi d'un message d'erreur Address already in use. -Problèmes avec DNS -Définition des adresses et ports +Problèmes avec DNS +Définition des adresses et ports qu'utilise le serveur HTTP Apache Autre -discussion à propos du message d'erreur Address already in +discussion à propos du message d'erreur Address already in use, citant d'autres causes possibles. ListenCoresBucketsRatio -Rapport entre le nombre de coeurs de processeur activés et -le nombre de segments d'écoute +Rapport entre le nombre de coeurs de processeur activés et +le nombre de segments d'écoute ListenCoresBucketsRatio ratio ListenCoresBucketsRatio 0 (disabled) server config eventworker prefork -Disponible à partir de la version 2.4.13 du serveur HTTP +Disponible à partir de la version 2.4.13 du serveur HTTP Apache, avec un noyau supportant l'option de socket -SO_REUSEPORT, et distribuant uniformément les nouvelles -connexions aux sockets d'écoute des processus (ou threads) qui -l'utilisent (par exemple Linux versions 3.9 et ultérieures, mais pas -l'implémentation courante de SO_REUSEPORT par les +SO_REUSEPORT, et distribuant uniformément les nouvelles +connexions aux sockets d'écoute des processus (ou threads) qui +l'utilisent (par exemple Linux versions 3.9 et ultérieures, mais pas +l'implémentation courante de SO_REUSEPORT par les plateformes de type BSD.

Vous pouvez utiliser la directive - ListenCoresBucketsRatio pour spécifier un - ratio entre le nombre de coeurs de CPU activés et le - nombre de segments d'écoute (listeners' buckets) souhaités ; le - serveur HTTP Apache va alors créernum_cpu_cores / ratio - segments d'écoute, chacun contenant son propre socket d'écoute - Listen sur le ou les mêmes ports ; chaque - processus enfant sera associé à un seul segment d'écoute (avec une - distribution de type round-robin des segments à la création des + ListenCoresBucketsRatio pour spécifier un + ratio entre le nombre de coeurs de CPU activés et le + nombre de segments d'écoute (listeners' buckets) souhaités ; le + serveur HTTP Apache va alors créernum_cpu_cores / ratio + segments d'écoute, chacun contenant son propre socket d'écoute + Listen sur le ou les mêmes ports ; chaque + processus enfant sera associé à un seul segment d'écoute (avec une + distribution de type round-robin des segments à la création des processus enfants).

+ Définition du terme coeur de CPU activé ("online") +

Sous Linux et BSD, un coeur de CPU peut être activé ou désactivé si Hotplug + a été configuré ; la directive + ListenCoresBucketsRatio doit donc tenir compte de ce + paramètre pour calculer le nombre de segments d'écoute à créer.

+ +

La directive ListenCoresBucketsRatio peut - améliorer le support de la montée en charge lorsque l'arrivée de - nouvelles connexions est/devient un goulot d'étranglement. Le test - de cette fonctionnalité avec des machines possédant un nombre de - coeurs de CPU important a permit de constater une amélioration des - performances significative et des temps de réponse plus courts.

- -

Pour que cette fonctionnalité soit activée, le nombre de coeurs - de CPU doit être égal au moins au double du ratio - spécifié. Si vous spécifiez la valeur recommandée pour - ratio, à savoir 8, le nombre minimum de - coeurs de processeurs disponibles sera alors de 16.

+ améliorer le support de la montée en charge lorsque l'arrivée de + nouvelles connexions est/devient un goulot d'étranglement. Le test + de cette fonctionnalité avec des machines possédant un nombre de + coeurs de CPU important a permit de constater une amélioration des + performances significative et des temps de réponse plus courts.

+ +

Pour que cette fonctionnalité soit activée, le nombre de coeurs + de CPU doit être égal au moins au double du ratio + spécifié. Si vous spécifiez la valeur recommandée pour + ratio, à savoir 8, le nombre minimum de + coeurs de processeurs disponibles sera alors de 16. La valeur + optimale de ratio permettant d'obtenir des performances maximales + doit être calculée pour chaque système cible, en testant plusieurs valeurs + et en observant les résultats.

 @@ -340,26 +351,26 @@ connexions

La longueur maximale de la liste d'attente des connexions. En - général, aucune modification n'est nécessaire, ni même souhaitable ; - cependant, sur certains systèmes, il peut être nécessaire + général, aucune modification n'est nécessaire, ni même souhaitable ; + cependant, sur certains systèmes, il peut être nécessaire d'en augmenter la valeur en cas d'attaque TCP SYN flood (envoi en - masse de requêtes SYN pour saturer le serveur). Voir le paramètre - backlog de l'appel système listen(2).

- -

En fait, l'argument backlog sera souvent limité à une valeur - inférieure en fonction du système d'exploitation. Notez aussi que de - nombreux systèmes d'exploitation ne tiennent pas vraiment compte de - la valeur spécifiée pour l'argument backlog, mais s'en inspirent - seulement (et choisissent en général une valeur supérieure).

+ masse de requêtes SYN pour saturer le serveur). Voir le paramètre + backlog de l'appel système listen(2).

+ +

En fait, l'argument backlog sera souvent limité à une valeur + inférieure en fonction du système d'exploitation. Notez aussi que de + nombreux systèmes d'exploitation ne tiennent pas vraiment compte de + la valeur spécifiée pour l'argument backlog, mais s'en inspirent + seulement (et choisissent en général une valeur supérieure).

 MaxRequestWorkers -Nombre maximum de connexions pouvant être traitées -simultanément +Nombre maximum de connexions pouvant être traitées +simultanément MaxRequestWorkers nombre -Voir ci-dessous pour plus de détails +Voir ci-dessous pour plus de détails server config eventworker prefork @@ -367,48 +378,48 @@ simultanément

La directive MaxRequestWorkers permet de fixer le - nombre maximum de requêtes pouvant être traitées simultanément. + nombre maximum de requêtes pouvant être traitées simultanément. Si la limite MaxRequestWorkers est atteinte, toute tentative de connexion sera normalement mise dans une file - d'attente, et ceci jusqu'à un certain nombre dépendant de la + d'attente, et ceci jusqu'à un certain nombre dépendant de la directive ListenBacklog. - Lorsqu'un processus enfant se libèrera suite à la fin du traitement - d'une requête, la connexion en attente pourra être traitée à son + Lorsqu'un processus enfant se libèrera suite à la fin du traitement + d'une requête, la connexion en attente pourra être traitée à son tour.

-

Pour les serveurs non threadés (c'est à dire utilisant +

Pour les serveurs non threadés (c'est à dire utilisant prefork), la directive - MaxRequestWorkers définit alors le nombre maximum de - processus enfants qui pourront être lancés simultanément pour - traiter les requêtes. La valeur par défaut est 256 ; si + MaxRequestWorkers définit alors le nombre maximum de + processus enfants qui pourront être lancés simultanément pour + traiter les requêtes. La valeur par défaut est 256 ; si vous l'augmentez, vous devez aussi augmenter la valeur de la directive ServerLimit.

-

Pour les serveur threadés et hybrides (utilisant par +

Pour les serveur threadés et hybrides (utilisant par exemple event ou worker), - MaxRequestWorkers définit alors le nombre total de + MaxRequestWorkers définit alors le nombre total de threads qui seront disponibles pour servir les clients. Dans le - cas des MPMs hybrides, la valeur par défaut est 16 + cas des MPMs hybrides, la valeur par défaut est 16 (directive ServerLimit) multiplié par la valeur + module="mpm_common">ServerLimit) multiplié par la valeur 25 (directive ThreadsPerChild). Par conséquent, pour affecter à la + >ThreadsPerChild). Par conséquent, pour affecter à la directive MaxRequestWorkers une valeur qui requiert plus de 16 processus, vous devez aussi augmenter la valeur de la directive ServerLimit.

Le nom de la directive MaxRequestWorkers - était MaxClients avant la version 2.3.13. Cet - ancien nom est encore supporté.

+ était MaxClients avant la version 2.3.13. Cet + ancien nom est encore supporté.

 MaxMemFree -Quantité maximale de mémoire que l'allocateur principal est -autorisé à conserver sans appeler free() +Quantité maximale de mémoire que l'allocateur principal est +autorisé à conserver sans appeler free() MaxMemFree KOctets MaxMemFree 2048 server config @@ -418,12 +429,12 @@ autorisé à conserver sans appeler free() -

La directive MaxMemFree permet de définir +

La directive MaxMemFree permet de définir le nombre maximum de KOctets libres que tout allocateur est - autorisé à conserver sans appeler free(). Dans les MPMs - threadés, chaque thread possède son propre allocateur. Si elle est - définie à 0, la quantité de mémoire libre que peut conserver un - allocateur est illimitée.

+ autorisé à conserver sans appeler free(). Dans les MPMs + threadés, chaque thread possède son propre allocateur. Si elle est + définie à 0, la quantité de mémoire libre que peut conserver un + allocateur est illimitée.

 @@ -440,20 +451,20 @@ traiter au cours de son fonctionnement Disponible depuis la version 2.3.9 du serveur HTTP Apache. L'ancien nom MaxRequestsPerChild est encore -supporté. +supporté.

La directive MaxConnectionsPerChild permet de - définir le nombre maximum de connexions qu'un processus enfant va - pouvoir traiter au cours de son fonctionnement. Lorsqu'il a traité + définir le nombre maximum de connexions qu'un processus enfant va + pouvoir traiter au cours de son fonctionnement. Lorsqu'il a traité MaxConnectionsPerChild connexions, le processus - enfant est arrêté. Si MaxConnectionsPerChild est - définie à 0, il n'y a plus aucune limite sur le nombre + enfant est arrêté. Si MaxConnectionsPerChild est + définie à 0, il n'y a plus aucune limite sur le nombre de connexions que le processus pourra traiter.

-

Définir MaxConnectionsPerChild à une valeur - non nulle limite la quantité de mémoire qu'un processus peut - consommer à cause de fuites (accidentelles) de mémoire.

+

Définir MaxConnectionsPerChild à une valeur + non nulle limite la quantité de mémoire qu'un processus peut + consommer à cause de fuites (accidentelles) de mémoire.

 @@ -462,7 +473,7 @@ supporté. MaxSpareThreads Nombre maximum de threads inactifs MaxSpareThreads nombre -Voir ci-dessous pour plus de détails +Voir ci-dessous pour plus de détails server config eventworker mpm_netwarempmt_os2 @@ -470,35 +481,35 @@ supporté.

C'est le nombre maximum de threads inactifs. Les MPMs utilisent - cette directive de différentes manières.

+ cette directive de différentes manières.

-

Pour worker et event, la définition par défaut est - MaxSpareThreads 250. Ce MPM gère les threads inactifs - au niveau du serveur. Si le serveur possède trop de threads - inactifs, des processus enfants seront arrêtés jusqu'à ce que le +

Pour worker et event, la définition par défaut est + MaxSpareThreads 250. Ce MPM gère les threads inactifs + au niveau du serveur. Si le serveur possède trop de threads + inactifs, des processus enfants seront arrêtés jusqu'à ce que le nombre de threads inactifs repasse en dessous de cette limite.

-

Pour mpm_netware, la définition par défaut est - MaxSpareThreads 100. Comme ce MPM n'exécute qu'un seul - processus, le nombre de processus inactifs est surveillé au +

Pour mpm_netware, la définition par défaut est + MaxSpareThreads 100. Comme ce MPM n'exécute qu'un seul + processus, le nombre de processus inactifs est surveillé au niveau du serveur.

-

mpmt_os2 fonctionne de manière similaire à +

mpmt_os2 fonctionne de manière similaire à mpm_netware. Pour mpmt_os2, la - valeur par défaut est 10.

+ valeur par défaut est 10.

Contraintes

La gamme de valeurs pour MaxSpareThreads - est limitée. Apache httpd corrigera automatiquement cette valeur selon - les règles suivantes :

+ est limitée. Apache httpd corrigera automatiquement cette valeur selon + les règles suivantes :

  • Avec mpm_netware, MaxSpareThreads doit être supérieure à MaxSpareThreads doit être supérieure à MinSpareThreads.
  • Avec worker et event, MaxSpareThreads - doit être supérieure ou égale à la somme de MinSpareThreads et ThreadsPerChild.
@@ -512,34 +523,34 @@ supporté. MinSpareThreads Nombre minimum de threads inactifs qui seront disponibles -pour pouvoir traiter les pics de requêtes +pour pouvoir traiter les pics de requêtes MinSpareThreads nombre -Voir ci-dessous pour plus de détails +Voir ci-dessous pour plus de détails server config eventworker mpm_netwarempmt_os2 -

C'est le nombre minimum de threads inactifs pour être en mesure - de traiter les pics de requêtes. Les MPMs utilisent cette directive - de différentes manières.

+

C'est le nombre minimum de threads inactifs pour être en mesure + de traiter les pics de requêtes. Les MPMs utilisent cette directive + de différentes manières.

-

Avec worker et event, la définition par défaut est +

Avec worker et event, la définition par défaut est MinSpareThreads 75, et le nombre de threads inactifs - est surveillé au niveau du serveur. Si le serveur ne possède pas - assez de threads inactifs, des processus enfants sont créés jusqu'à + est surveillé au niveau du serveur. Si le serveur ne possède pas + assez de threads inactifs, des processus enfants sont créés jusqu'à ce que le nombre de threads inactifs repasse au dessus de nombre.

-

Avec mpm_netware, la définition par défaut est - MinSpareThreads 10 et, comme ce MPM n'exécute qu'un - seul processus, le nombre de threads est surveillé au niveau du +

Avec mpm_netware, la définition par défaut est + MinSpareThreads 10 et, comme ce MPM n'exécute qu'un + seul processus, le nombre de threads est surveillé au niveau du serveur.

-

mpmt_os2 fonctionne de manière similaire à +

mpmt_os2 fonctionne de manière similaire à mpm_netware. Pour mpmt_os2, la - valeur par défaut est 5.

+ valeur par défaut est 5.

 MaxSpareThreads @@ -549,7 +560,7 @@ pour pouvoir traiter les pics de requêtes ScoreBoardFile -Chemin du fichier où sont stockées les données concernant +Chemin du fichier où sont stockées les données concernant la coordination des processus enfants ScoreBoardFile chemin fichier ScoreBoardFile logs/apache_runtime_status @@ -562,13 +573,13 @@ la coordination des processus enfants

Le serveur HTTP Apache utilise un tableau de bord pour la communication entre le processus parent et les processus enfants. Pour faciliter cette communication, certaines architectures - nécessitent un fichier. En l'absence de cette directive, donc si - aucun nom de fichier n'est spécifié, Apache httpd tentera tout - d'abord de créer un tableau uniquement en mémoire (en utilisant la - mémoire partagée anonyme) ; et si il n'y parvient pas, il tentera de - créer un fichier sur disque (en utilisant la mémoire partagée à base - de fichier). Si cette directive est utilisée, Apache httpd créera - systématiquement un fichier sur disque.

+ nécessitent un fichier. En l'absence de cette directive, donc si + aucun nom de fichier n'est spécifié, Apache httpd tentera tout + d'abord de créer un tableau uniquement en mémoire (en utilisant la + mémoire partagée anonyme) ; et si il n'y parvient pas, il tentera de + créer un fichier sur disque (en utilisant la mémoire partagée à base + de fichier). Si cette directive est utilisée, Apache httpd créera + systématiquement un fichier sur disque.

Exemple @@ -576,24 +587,24 @@ la coordination des processus enfants -

Une mémoire partagée sous forme de fichier est utile pour les - applications tierces qui nécessitent un accès direct au tableau de +

Une mémoire partagée sous forme de fichier est utile pour les + applications tierces qui nécessitent un accès direct au tableau de bord des processus.

Si vous utilisez un ScoreBoardFile, vous - pourrez constater une amélioration des performances en le plaçant + pourrez constater une amélioration des performances en le plaçant sur un disque virtuel en RAM. Assurez-vous cependant de tenir compte - des mêmes avertissements que ceux concernant le chemin du fichier + des mêmes avertissements que ceux concernant le chemin du fichier journal et la sécurité.

+ href="../misc/security_tips.html">sécurité.

 -Arrêter et redémarrer +Arrêter et redémarrer le serveur HTTP Apache ReceiveBufferSize -Taille du tampon TCP en entrée +Taille du tampon TCP en entrée ReceiveBufferSize octets ReceiveBufferSize 0 server config @@ -603,11 +614,11 @@ le serveur HTTP Apache -

Le serveur va fixer la taille du tampon TCP en entrée au - nombre d'octets spécifié.

+

Le serveur va fixer la taille du tampon TCP en entrée au + nombre d'octets spécifié.

-

Si la directive est définie à 0, le serveur va - utiliser la valeur par défaut adoptée par le système +

Si la directive est définie à 0, le serveur va + utiliser la valeur par défaut adoptée par le système d'exploitation.

 @@ -624,104 +635,104 @@ le serveur HTTP Apache -

Définit la taille du tampon TCP en sortie avec le nombre - d'octets spécifié. Ceci s'avère souvent très utile pour augmenter les - valeurs par défaut standards du passé des systèmes d'exploitation - pour les transmissions à grande vitesse et haute densité (c'est - à dire de l'ordre de 100ms comme sur les liaisons rapides +

Définit la taille du tampon TCP en sortie avec le nombre + d'octets spécifié. Ceci s'avère souvent très utile pour augmenter les + valeurs par défaut standards du passé des systèmes d'exploitation + pour les transmissions à grande vitesse et haute densité (c'est + à dire de l'ordre de 100ms comme sur les liaisons rapides transcontinentales).

-

Si la directive est définie à 0, le serveur va - utiliser la valeur par défaut adoptée par le système +

Si la directive est définie à 0, le serveur va + utiliser la valeur par défaut adoptée par le système d'exploitation.

-

L'amélioration des performances des connexions à grande vitesse - et à temps de latence élevé, peut nécessiter - une intervention au niveau de la configuration de votre système +

L'amélioration des performances des connexions à grande vitesse + et à temps de latence élevé, peut nécessiter + une intervention au niveau de la configuration de votre système d'exploitation.

-

Sous certains systèmes d'exploitation, la modification du +

Sous certains systèmes d'exploitation, la modification du comportement TCP via une augmentation de la valeur de - SendBufferSize risque de ne pas être + SendBufferSize risque de ne pas être perceptible, si la directive EnableSendfile n'est pas définie à OFF. + module="core">EnableSendfile n'est pas définie à OFF. Cette interaction ne s'applique qu'aux fichiers statiques.

 ServerLimit -Limite supérieure de la définition du nombre de +Limite supérieure de la définition du nombre de processus ServerLimit nombre -Voir ci-dessous pour plus de détails +Voir ci-dessous pour plus de détails server config eventworker prefork -

Avec le MPM prefork, cette directive définit le - nombre maximum que l'on peut affecter à la directive Avec le MPM prefork, cette directive définit le + nombre maximum que l'on peut affecter à la directive MaxRequestWorkers, et ceci pour la - durée de vie du processus Apache httpd. Avec les + durée de vie du processus Apache httpd. Avec les MPMs worker et event, cette directive, en combinaison avec - ThreadLimit, définit le - nombre maximum que l'on peut affecter à MaxRequestWorkers, et ceci pour la durée de - vie du processus Apache httpd. Au cours d'un redémarrage, vous pouvez + ThreadLimit, définit le + nombre maximum que l'on peut affecter à MaxRequestWorkers, et ceci pour la durée de + vie du processus Apache httpd. Au cours d'un redémarrage, vous pouvez modifier la valeur de la directive MaxRequestWorkers, alors que toute tentative de modification de la valeur de la directive ServerLimit sera ignorée.

+ module="mpm_common">ServerLimit sera ignorée.

-

Cette directive doit être utilisée avec précaution. Si - ServerLimit est définie à une valeur beaucoup - plus grande que nécessaire, de la mémoire partagée supplémentaire - sera inutilement allouée. Si à la fois +

Cette directive doit être utilisée avec précaution. Si + ServerLimit est définie à une valeur beaucoup + plus grande que nécessaire, de la mémoire partagée supplémentaire + sera inutilement allouée. Si à la fois ServerLimit et MaxRequestWorkers possèdent des valeurs - supérieures à ce que le système peut supporter, ce dernier peut - devenir instable ou Apache httpd peut tout simplement refuser de démarrer.

+ module="mpm_common">MaxRequestWorkers possèdent des valeurs + supérieures à ce que le système peut supporter, ce dernier peut + devenir instable ou Apache httpd peut tout simplement refuser de démarrer.

Avec les MPMs prefork et event, n'utilisez cette directive - que si vous devez définir MaxRequestWorkers à une valeur supérieure à - 256 (valeur par défaut). N'affectez pas à la directive ServerLimit une valeur supérieure à - celle que vous avez prévu d'affecter à la directive MaxRequestWorkers à une valeur supérieure à + 256 (valeur par défaut). N'affectez pas à la directive ServerLimit une valeur supérieure à + celle que vous avez prévu d'affecter à la directive MaxRequestWorkers.

Avec worker, n'utilisez cette directive que si - la définition de vos directives MaxRequestWorkers et ThreadsPerChild nécessitent plus de - 16 processus serveurs (valeur par défaut). N'affectez pas à la + module="mpm_common">ThreadsPerChild nécessitent plus de + 16 processus serveurs (valeur par défaut). N'affectez pas à la directive ServerLimit une - valeur supérieure au nombre de processus requis pour la définition + valeur supérieure au nombre de processus requis pour la définition des directives MaxRequestWorkers et ThreadsPerChild.

Note -

Il existe une limite de ServerLimit 20000 codée en +

Il existe une limite de ServerLimit 20000 codée en dur dans le serveur (200000 pour le MPM prefork). - Ceci est censé éviter les effets désastreux que pourrait provoquer - une faute de frappe. Pour dépasser cette limite, vous devez + Ceci est censé éviter les effets désastreux que pourrait provoquer + une faute de frappe. Pour dépasser cette limite, vous devez modifier la valeur de MAX_SERVER_LIMIT dans le fichier source du mpm et recompiler le serveur.

 -Arrêter et redémarrer +Arrêter et redémarrer le serveur HTTP Apache StartServers -Nombre de processus enfants du serveur créés au -démarrage +Nombre de processus enfants du serveur créés au +démarrage StartServers nombre -Voir ci-dessous pour plus de détails +Voir ci-dessous pour plus de détails server config eventworker preforkmpmt_os2 @@ -729,18 +740,18 @@ démarrage

La directive StartServers permet de - définir le nombre de processus enfants du serveur créés au - démarrage. Comme le nombre de processus est contrôlé dynamiquement + définir le nombre de processus enfants du serveur créés au + démarrage. Comme le nombre de processus est contrôlé dynamiquement en fonction de la charge (voir MinSpareThreads, MaxSpareThreads, MinSpareServers, MaxSpareServers), il n'est en général - pas nécessaire d'ajuster ce paramètre.

+ module="prefork">MaxSpareServers), il n'est en général + pas nécessaire d'ajuster ce paramètre.

-

La valeur par défaut diffère d'un MPM à l'autre. Pour - worker et event, la définition par défaut est - StartServers 3 ; la valeur par défaut est +

La valeur par défaut diffère d'un MPM à l'autre. Pour + worker et event, la définition par défaut est + StartServers 3 ; la valeur par défaut est 5 pour prefork et 2 pour mpmt_os2.

 @@ -748,67 +759,67 @@ démarrage StartThreads -Nombre de threads créés au démarrage +Nombre de threads créés au démarrage StartThreads nombre -Voir ci-dessous pour plus de détails +Voir ci-dessous pour plus de détails server config mpm_netware -

C'est le nombre de threads créés au démarrage du serveur. Comme - le nombre de threads est contrôlé dynamiquement +

C'est le nombre de threads créés au démarrage du serveur. Comme + le nombre de threads est contrôlé dynamiquement en fonction de la charge (voir MinSpareThreads, MaxSpareThreads, MinSpareServers, MaxSpareServers), il n'est en général - pas nécessaire d'ajuster ce paramètre.

+ module="prefork">MaxSpareServers), il n'est en général + pas nécessaire d'ajuster ce paramètre.

-

Pour mpm_netware, la définition par défaut est +

Pour mpm_netware, la définition par défaut est StartThreads 50 et, comme il n'y a qu'un processus, il - s'agit du nombre total de threads créés au démarrage pour servir les - requêtes.

+ s'agit du nombre total de threads créés au démarrage pour servir les + requêtes.

 ThreadLimit -Le nombre de threads maximum que l'on peut définir par +Le nombre de threads maximum que l'on peut définir par processus enfant ThreadLimit nombre -Voir ci-dessous pour plus de détails +Voir ci-dessous pour plus de détails server config eventworker mpm_winnt -

Cette directive permet de définir le nombre maximum que l'on peut - affecter à la directive ThreadsPerChild pour la durée de vie +

Cette directive permet de définir le nombre maximum que l'on peut + affecter à la directive ThreadsPerChild pour la durée de vie du processus Apache httpd. La directive ThreadsPerChild peut être modifiée - au cours d'un redémarrage jusqu'à la valeur de la directive ThreadsPerChild peut être modifiée + au cours d'un redémarrage jusqu'à la valeur de la directive ThreadLimit, mais toute tentative de modification de la directive ThreadLimit au cours d'un - redémarrage sera ignorée.

+ redémarrage sera ignorée.

L'utilisation de cette directive doit faire l'objet de - précautions particulières. Si ThreadLimit est - définie à une valeur très supérieure à la directive ThreadsPerChild, de la mémoire - partagée supplémentaire sera inutilement allouée. Si les directives + précautions particulières. Si ThreadLimit est + définie à une valeur très supérieure à la directive ThreadsPerChild, de la mémoire + partagée supplémentaire sera inutilement allouée. Si les directives ThreadLimit et ThreadsPerChild sont définies à des - valeurs supérieures à ce que le système peut supporter, ce dernier + module="mpm_common">ThreadsPerChild sont définies à des + valeurs supérieures à ce que le système peut supporter, ce dernier peut devenir instable, ou Apache httpd peut tout simplement refuser de - démarrer. Ne définissez pas cette directive à une valeur supérieure - à la valeur maximale que vous pensez affecter à la directive ThreadsPerChild pour le processus - Apache httpd en cours d'exécution.

+ Apache httpd en cours d'exécution.

-

La valeur par défaut de la directive +

La valeur par défaut de la directive ThreadLimit est 1920 avec mpm_winnt, et 64 avec les autres MPMs.

@@ -817,9 +828,9 @@ processus enfant

Il existe une limite de ThreadLimit 20000 (ou ThreadLimit 100000 avec event, ThreadLimit 15000 avec mpm_winnt) - codée en dur dans le serveur. Ceci est censé éviter les effets - désastreux que pourrait provoquer une faute de frappe. Pour - dépasser cette limite, vous devez modifier la valeur de + codée en dur dans le serveur. Ceci est censé éviter les effets + désastreux que pourrait provoquer une faute de frappe. Pour + dépasser cette limite, vous devez modifier la valeur de MAX_THREAD_LIMIT dans le fichier source du mpm et recompiler le serveur.

@@ -828,27 +839,27 @@ processus enfant ThreadsPerChild -Nombre de threads créés par chaque processus +Nombre de threads créés par chaque processus enfant ThreadsPerChild nombre -Voir ci-dessous pour plus de détails +Voir ci-dessous pour plus de détails server config eventworker mpm_winnt -

Cette directive permet de définir le nombre de threads que va - créer chaque processus enfant. Un processus enfant crée ces threads - au démarrage et n'en crée plus d'autres par la suite. Si l'on +

Cette directive permet de définir le nombre de threads que va + créer chaque processus enfant. Un processus enfant crée ces threads + au démarrage et n'en crée plus d'autres par la suite. Si l'on utilise un MPM comme mpm_winnt qui ne lance qu'un - processus enfant, ce nombre doit être suffisamment grand pour + processus enfant, ce nombre doit être suffisamment grand pour supporter la charge du serveur. Avec un MPM comme worker qui lance plusieurs processus enfants, c'est - le nombre total de threads qui doit être suffisamment grand + le nombre total de threads qui doit être suffisamment grand pour supporter la charge du serveur.

-

La valeur par défaut de la directive +

La valeur par défaut de la directive ThreadsPerChild est 64 avec mpm_winnt, et 25 avec les autres MPMs.

@@ -860,68 +871,68 @@ enfant La taille en octets de la pile qu'utilisent les threads qui traitent les connexions clients ThreadStackSize taille -65536 sous NetWare; varie en fonction des autres systèmes +65536 sous NetWare; varie en fonction des autres systèmes d'exploitation server config eventworker mpm_winntmpm_netware mpmt_os2 -Disponible dans les versions 2.1 et supérieures +Disponible dans les versions 2.1 et supérieures du serveur HTTP Apache

La directive ThreadStackSize permet de - définir la taille de la pile (pour les données propres) qu'utilisent - les threads qui traitent les connexions clients en faisant appel à - des modules. Dans la plupart des cas, la valeur par défaut de la - taille de la pile du système d'exploitation convient, mais il existe - certaines situations où il peut s'avérer nécessaire de l'ajuster + définir la taille de la pile (pour les données propres) qu'utilisent + les threads qui traitent les connexions clients en faisant appel à + des modules. Dans la plupart des cas, la valeur par défaut de la + taille de la pile du système d'exploitation convient, mais il existe + certaines situations où il peut s'avérer nécessaire de l'ajuster :

    -
  • Sur les plates-formes qui possèdent une valeur par défaut de +
  • Sur les plates-formes qui possèdent une valeur par défaut de taille de la pile relativement petite (par exemple HP-UX), Apache httpd peut se crasher si l'on utilise certains modules tiers qui - possèdent un quantité de données propres stockées relativement - importante. Il se peut que ces mêmes modules fonctionnent - correctement sur d'autres plate-formes où la valeur par défaut de - la taille de la pile est supérieure. Ce type de crash peut être - evité en définissant ThreadStackSize à une - valeur supérieure à la valeur par défaut du système - d'exploitation. Ce type d'ajustement n'est nécessaire que si le + possèdent un quantité de données propres stockées relativement + importante. Il se peut que ces mêmes modules fonctionnent + correctement sur d'autres plate-formes où la valeur par défaut de + la taille de la pile est supérieure. Ce type de crash peut être + evité en définissant ThreadStackSize à une + valeur supérieure à la valeur par défaut du système + d'exploitation. Ce type d'ajustement n'est nécessaire que si le fournisseur du module tiers en fait mention, ou si le diagnostic - d'un crash d'Apache httpd indique que la taille de la pile était trop + d'un crash d'Apache httpd indique que la taille de la pile était trop petite.
    • -
  • Sur les plates-formes où la taille par défaut de la pile des - threads est sensiblement supérieure à la taille nécessaire pour la +
  • Sur les plates-formes où la taille par défaut de la pile des + threads est sensiblement supérieure à la taille nécessaire pour la configuration du serveur web, il est possible de disposer d'un plus grand nombre de threads par processus enfant si la directive - ThreadStackSize est définie à une valeur - inférieure à la valeur par défaut du système d'exploitation. + ThreadStackSize est définie à une valeur + inférieure à la valeur par défaut du système d'exploitation. Cependant, ce - type d'ajustement ne doit être effectué que dans un environnement + type d'ajustement ne doit être effectué que dans un environnement de test permettant de qualifier le serveur web au maximum de ses - possibilités, car il peut arriver, dans de rares cas, que des - requêtes nécessitent une taille de pile supérieure pour pouvoir - être traitées. La taille minimale requise pour la pile dépend - fortement des modules utilisés, mais toute modification dans la - configuration du serveur web peut invalider la définition courante + possibilités, car il peut arriver, dans de rares cas, que des + requêtes nécessitent une taille de pile supérieure pour pouvoir + être traitées. La taille minimale requise pour la pile dépend + fortement des modules utilisés, mais toute modification dans la + configuration du serveur web peut invalider la définition courante de la directive ThreadStackSize.
    • -
  • Sous Linux, cette directive ne peut être utilisée que pour +
  • Sous Linux, cette directive ne peut être utilisée que pour augmenter la valeur par defaut de la taille de la pile, car - l'appel système sous-jacent utilise cette valeur comme taille de pile - minimale. C'est la limite logicielle (souvent élevée) + l'appel système sous-jacent utilise cette valeur comme taille de pile + minimale. C'est la limite logicielle (souvent élevée) pour ulimit -s (8Mo si aucune limite) qui est - utilisée comme taille de pile par défaut.
    • + utilisée comme taille de pile par défaut.
- Il est recommandé de ne pas réduire - ThreadStackSize, à moins qu'un grand nombre - de threads par processus enfant ne soit nécessaire. Sur certaines - plates-formes (y compris Linux), une valeur de 128000 est déjà trop + Il est recommandé de ne pas réduire + ThreadStackSize, à moins qu'un grand nombre + de threads par processus enfant ne soit nécessaire. Sur certaines + plates-formes (y compris Linux), une valeur de 128000 est déjà trop basse et provoque des crashes avec certains modules courants.