From: Lucien Gentis Date: Sat, 19 Nov 2016 17:17:50 +0000 (+0000) Subject: XML updates. X-Git-Tag: 2.4.24~120 X-Git-Url: http://git.ipfire.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=26922c4d6dc5a835a0c8c433ae91b596b2e4df7f;p=thirdparty%2Fapache%2Fhttpd.git XML updates. git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/branches/2.4.x@1770508 13f79535-47bb-0310-9956-ffa450edef68 --- diff --git a/docs/manual/mod/mod_lbmethod_bybusyness.xml.fr b/docs/manual/mod/mod_lbmethod_bybusyness.xml.fr index 4eea60ef939..034befead0a 100644 --- a/docs/manual/mod/mod_lbmethod_bybusyness.xml.fr +++ b/docs/manual/mod/mod_lbmethod_bybusyness.xml.fr @@ -1,4 +1,4 @@ - + @@ -25,43 +25,43 @@ mod_lbmethod_bybusyness -Algorithme de planification avec répartition de charge de -l'attribution des requêtes en attente pour le module +Algorithme de planification avec répartition de charge de +l'attribution des requêtes en attente pour le module mod_proxy_balancer Extension mod_lbmethod_bybusyness.c lbmethod_bybusyness_module -Dissocié de mod_proxy_balancer depuis la +Dissocié de mod_proxy_balancer depuis la version 2.3 -

Ce module ne fournit pas lui-même de directive de configuration. Il -nécessite les services de mod_proxy_balancer, et -fournit la méthode de répartition de charge bybusyness.

+

Ce module ne fournit pas lui-même de directive de configuration. Il +nécessite les services de mod_proxy_balancer, et +fournit la méthode de répartition de charge bybusyness.

 mod_proxy mod_proxy_balancer
- Algorithme d'attribution des requêtes en attente + Algorithme d'attribution des requêtes en attente -

Activé via lbmethod=bybusyness, ce planificateur - surveille le nombre de requêtes assignées à chaque processus worker - à l'instant présent. Une nouvelle requête est automatiquement - assignée au processus worker auquel est assigné le plus petit nombre de - requêtes. Ceci s'avère utile dans le cas où les - processus worker mettent en file d'attente les requêtes entrantes - indépendamment d'Apache, et permet de s'assurer que la longueur des - files reste raisonnable, et qu'une requête est toujours assignée au - processus worker qui sera à même de la servir le plus - rapidement et avec une latence réduite.

+

Activé via lbmethod=bybusyness, ce planificateur + surveille le nombre de requêtes assignées à chaque processus worker + à l'instant présent. Une nouvelle requête est automatiquement + assignée au processus worker auquel est assigné le plus petit nombre de + requêtes. Ceci s'avère utile dans le cas où les + processus worker mettent en file d'attente les requêtes entrantes + indépendamment d'Apache, et permet de s'assurer que la longueur des + files reste raisonnable, et qu'une requête est toujours assignée au + processus worker qui sera à même de la servir le plus + rapidement et avec une latence réduite.

-

Si plusieurs processus worker s'avèrent les moins chargés, le - choix d'un de ces derniers est effectué à partir des statistiques - (et des estimations de charges) qu'utilise la méthode de décompte - des requêtes. Au fil du temps, la distribution des tâches finit par - ressembler à celle de byrequests (tel qu'implémenté par +

Si plusieurs processus worker s'avèrent les moins chargés, le + choix d'un de ces derniers est effectué à partir des statistiques + (et des estimations de charges) qu'utilise la méthode de décompte + des requêtes. Au fil du temps, la distribution des tâches finit par + ressembler à celle de byrequests (tel qu'implémenté par mod_lbmethod_byrequests).

diff --git a/docs/manual/mod/mod_lbmethod_byrequests.xml.fr b/docs/manual/mod/mod_lbmethod_byrequests.xml.fr index 702d1562add..816d8799523 100644 --- a/docs/manual/mod/mod_lbmethod_byrequests.xml.fr +++ b/docs/manual/mod/mod_lbmethod_byrequests.xml.fr @@ -1,4 +1,4 @@ - + @@ -25,53 +25,53 @@ mod_lbmethod_byrequests -Algorithme de planification avec répartition de charge du -traitement des requêtes pour le module +Algorithme de planification avec répartition de charge du +traitement des requêtes pour le module mod_proxy_balancer Extension mod_lbmethod_byrequests.c lbmethod_byrequests_module -Dissocié de mod_proxy_balancer dans la +Dissocié de mod_proxy_balancer dans la version 2.3 -

Ce module ne fournit pas lui-même de directive de configuration. Il -nécessite les services de mod_proxy_balancer, et -fournit la méthode de répartition de charge byrequests.

+

Ce module ne fournit pas lui-même de directive de configuration. Il +nécessite les services de mod_proxy_balancer, et +fournit la méthode de répartition de charge byrequests.

 mod_proxy mod_proxy_balancer
- Algorithme d'attribution des requêtes -

Activé via lbmethod=byrequests, ce planificateur à - été conçu dans le but de distribuer les requêtes à tous les - processus worker afin qu'ils traitent tous le nombre de requêtes - pour lequel ils ont été configurés. Il fonctionne de la manière + Algorithme d'attribution des requêtes +

Activé via lbmethod=byrequests, ce planificateur à + été conçu dans le but de distribuer les requêtes à tous les + processus worker afin qu'ils traitent tous le nombre de requêtes + pour lequel ils ont été configurés. Il fonctionne de la manière suivante :

-

lbfactor correspond à la quantité de travail que +

lbfactor correspond à la quantité de travail que nous attendons de ce processus worker, ou en d'autres termes - son quota de travail. C'est une valeur normalisée - représentant leur part du travail à accomplir.

+ son quota de travail. C'est une valeur normalisée + représentant leur part du travail à accomplir.

-

lbstatus représente combien il est urgent que +

lbstatus représente combien il est urgent que ce processus worker travaille pour remplir son quota de travail.

-

Le worker est un membre du dispositif de répartition - de charge, en général un serveur distant traitant un des protocoles - supportés.

+

Le worker est un membre du dispositif de répartition + de charge, en général un serveur distant traitant un des protocoles + supportés.

-

On distribue à chaque processus worker son quota de travail, puis +

On distribue à chaque processus worker son quota de travail, puis on regarde celui qui a le plus besoin de travailler - (le plus grand lbstatus). Ce processus est alors sélectionné pour - travailler, et son lbstatus diminué de l'ensemble des quotas de - travail que nous avons distribués à tous les processus. La somme de - tous les lbstatus n'est ainsi pas modifiée, et nous pouvons - distribuer les requêtes selon nos souhaits.

+ (le plus grand lbstatus). Ce processus est alors sélectionné pour + travailler, et son lbstatus diminué de l'ensemble des quotas de + travail que nous avons distribués à tous les processus. La somme de + tous les lbstatus n'est ainsi pas modifiée, et nous pouvons + distribuer les requêtes selon nos souhaits.

-

Si certains processus workers sont désactivés, les autres feront +

Si certains processus workers sont désactivés, les autres feront l'objet d'une planification normale.

for each worker in workers
@@ -83,7 +83,7 @@ fournit la méthode de répartition de charge byrequests
 -

Si un répartiteur de charge est configuré comme suit :

+

Si un répartiteur de charge est configuré comme suit :

@@ -103,7 +103,7 @@ candidate lbstatus -= total factor
worker 0
-

Et si b est désactivé, la planification suivante est +

Et si b est désactivé, la planification suivante est mise en oeuvre :

@@ -130,7 +130,7 @@ candidate lbstatus -= total factor
(repeat)
-

C'est à dire la chronologie suivante : a c +

C'est à dire la chronologie suivante : a c d a c d a c d ... Veuillez noter que :

@@ -148,7 +148,7 @@ candidate lbstatus -= total factor 25 -

A le même effet que :

+

A le même effet que :

@@ -163,8 +163,8 @@ candidate lbstatus -= total factor
worker 1
-

Ceci est dû au fait que toutes les valeurs de lbfactor - sont normalisées et évaluées en fonction des autres. Avec :

+

Ceci est dû au fait que toutes les valeurs de lbfactor + sont normalisées et évaluées en fonction des autres. Avec :

@@ -178,9 +178,9 @@ candidate lbstatus -= total factor
worker

le processus b va, en moyenne, se voir assigner 4 fois - plus de requêtes que a et c.

+ plus de requêtes que a et c.

-

La configuration suivante, asymétrique, fonctionne comme on peut +

La configuration suivante, asymétrique, fonctionne comme on peut s'y attendre :

@@ -224,8 +224,8 @@ candidate lbstatus -= total factor
(repeat)
-

Après 10 distributions, la planification se répète et 7 - a sont sélectionnés avec 3 b intercalés.

+

Après 10 distributions, la planification se répète et 7 + a sont sélectionnés avec 3 b intercalés.

 diff --git a/docs/manual/mod/mod_lbmethod_bytraffic.xml.fr b/docs/manual/mod/mod_lbmethod_bytraffic.xml.fr index 98567f5773a..68e8451a364 100644 --- a/docs/manual/mod/mod_lbmethod_bytraffic.xml.fr +++ b/docs/manual/mod/mod_lbmethod_bytraffic.xml.fr @@ -1,4 +1,4 @@ - + @@ -25,38 +25,38 @@ mod_lbmethod_bytraffic -Algorithme de planification avec répartition de charge en +Algorithme de planification avec répartition de charge en fonction d'un niveau de trafic pour le module mod_proxy_balancer Extension mod_lbmethod_bytraffic.c lbmethod_bytraffic_module -Dissocié de mod_proxy_balancer depuis la +Dissocié de mod_proxy_balancer depuis la version 2.3 -

Ce module ne fournit pas lui-même de directive de configuration. Il -nécessite les services de mod_proxy_balancer, et -fournit la méthode de répartition de charge bytraffic.

+

Ce module ne fournit pas lui-même de directive de configuration. Il +nécessite les services de mod_proxy_balancer, et +fournit la méthode de répartition de charge bytraffic.

 mod_proxy mod_proxy_balancer
- Algorithme de répartition en fonction d'un certain + <title>Algorithme de répartition en fonction d'un certain trafic -

Activé via lbmethod=bytraffic, l'idée directrice de - ce planificateur est similaire à celle de la méthode reposant sur le - nombre de requêtes, avec les différences suivantes :

+

Activé via lbmethod=bytraffic, l'idée directrice de + ce planificateur est similaire à celle de la méthode reposant sur le + nombre de requêtes, avec les différences suivantes :

-

lbfactor représente la quantité de trafic, en - octets, que nous voulons voir traitée par le processus. Il - s'agit là aussi d'une valeur normalisée représentant la part de - travail à effectuer par le processus, mais au lieu de se baser sur - un nombre de requêtes, on prend en compte la quantité de trafic que - ce processus a traité.

+

lbfactor représente la quantité de trafic, en + octets, que nous voulons voir traitée par le processus. Il + s'agit là aussi d'une valeur normalisée représentant la part de + travail à effectuer par le processus, mais au lieu de se baser sur + un nombre de requêtes, on prend en compte la quantité de trafic que + ce processus a traité.

-

Si un répartiteur est configuré comme suit :

+

Si un répartiteur est configuré comme suit :

@@ -70,14 +70,14 @@ fournit la méthode de répartition de charge bytraffic
worker

Cela signifie que nous souhaitons que b traite 2 fois - plus d'octets que a ou c. Cela n'entraîne pas - nécessairement que b va traiter deux fois plus de - requêtes, mais qu'il va traiter deux fois plus de trafic en termes - d'entrées/sorties. A cet effet, les tailles de la requête et de sa - réponse assocciée sont prises en compte par l'algorithme de - sélection et d'évaluation du trafic.

+ plus d'octets que a ou c. Cela n'entraîne pas + nécessairement que b va traiter deux fois plus de + requêtes, mais qu'il va traiter deux fois plus de trafic en termes + d'entrées/sorties. A cet effet, les tailles de la requête et de sa + réponse assocciée sont prises en compte par l'algorithme de + sélection et d'évaluation du trafic.

-

Note : les octets en entrée sont évalués avec la même pondération +

Note : les octets en entrée sont évalués avec la même pondération que les octets en sortie.

diff --git a/docs/manual/mod/mod_lbmethod_heartbeat.xml.fr b/docs/manual/mod/mod_lbmethod_heartbeat.xml.fr index 4cde9477704..8e9854a4441 100644 --- a/docs/manual/mod/mod_lbmethod_heartbeat.xml.fr +++ b/docs/manual/mod/mod_lbmethod_heartbeat.xml.fr @@ -1,4 +1,4 @@ - + @@ -25,8 +25,8 @@ mod_lbmethod_heartbeat -Algorithme d'ordonnancement de répartition de charge pour -mod_proxy_balancer basé sur le comptage de trafic Heartbeat +Algorithme d'ordonnancement de répartition de charge pour +mod_proxy_balancer basé sur le comptage de trafic Heartbeat Experimental mod_lbmethod_heartbeat.c lbmethod_heartbeat_module @@ -34,16 +34,16 @@

lbmethod=heartbeat utilise les services du module - mod_heartmonitor pour répartir la charge entre les - serveurs d'origine qui fournissent des données heartbeat via le + mod_heartmonitor pour répartir la charge entre les + serveurs d'origine qui fournissent des données heartbeat via le module mod_heartbeat.

-

Son algorithme de répartition de charge favorise les serveurs dont la -capacité de traitement moyenne répartie dans le temps est la plus -importante, mais il ne sélectionne pas forcément le serveur qui présente -la disponibilité instantanée la plus importante. Les serveurs qui ne -possèdent aucun client actif sont pénalisés, car ils sont considérés -comme non entièrement initialisés.

+

Son algorithme de répartition de charge favorise les serveurs dont la +capacité de traitement moyenne répartie dans le temps est la plus +importante, mais il ne sélectionne pas forcément le serveur qui présente +la disponibilité instantanée la plus importante. Les serveurs qui ne +possèdent aucun client actif sont pénalisés, car ils sont considérés +comme non entièrement initialisés.

 mod_proxy @@ -53,7 +53,7 @@ comme non entièrement initialisés.

HeartbeatStorage -Indique le chemin permettant de lire les données +Indique le chemin permettant de lire les données heartbeat HeartbeatStorage chemin-fichier HeartbeatStorage logs/hb.dat @@ -61,9 +61,9 @@ heartbeat

La directive HeartbeatStorage permet de - spécifier le chemin d'accès aux données heartbeat. Ce fichier texte - n'est utilisé que si le module mod_slotmem_shm - n'est pas chargé.

+ spécifier le chemin d'accès aux données heartbeat. Ce fichier texte + n'est utilisé que si le module mod_slotmem_shm + n'est pas chargé.