Serveur Apache HTTP Version 2.4

| Description: | Algorithme de planification avec r�partition de charge du
traitement des requ�tes pour le module
mod_proxy_balancer |
|---|---|
| Statut: | Extension |
| Identificateur�de�Module: | lbmethod_byrequests_module |
| Fichier�Source: | mod_lbmethod_byrequests.c |
| Compatibilit�: | 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 aucune directive.
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 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.
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.
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.
Si certains processus workers sont d�sactiv�s, les autres feront l'objet d'une planification normale.
for each worker in workers
worker lbstatus += worker lbfactor
total factor += worker lbfactor
if worker lbstatus > candidate lbstatus
candidate = worker
candidate lbstatus -= total factorSi un r�partiteur de charge est configur� comme suit :
| worker | a | b | c | d |
|---|---|---|---|---|
| lbfactor | 25 | 25 | 25 | 25 |
| lbstatus | 0 | 0 | 0 | 0 |
Et si b est d�sactiv�, la planification suivante est mise en oeuvre :
| worker | a | b | c | d |
|---|---|---|---|---|
| lbstatus | -50 | 0 | 25 | 25 |
| lbstatus | -25 | 0 | -25 | 50 |
| lbstatus | 0 | 0 | 0 | 0 |
| (repeat) | ||||
C'est � dire la chronologie suivante : a c d a c d a c d ... Veuillez noter que :
| worker | a | b | c | d |
|---|---|---|---|---|
| lbfactor | 25 | 25 | 25 | 25 |
A le m�me effet que :
| worker | a | b | c | d |
|---|---|---|---|---|
| lbfactor | 1 | 1 | 1 | 1 |
Ceci est d� au fait que toutes les valeurs de lbfactor sont normalis�es et �valu�es en fonction des autres. Avec :
| worker | a | b | c |
|---|---|---|---|
| lbfactor | 1 | 4 | 1 |
le processus b va, en moyenne, se voir assigner 4 fois plus de requ�tes que a et c.
La configuration suivante, asym�trique, fonctionne comme on peut s'y attendre :
| worker | a | b |
|---|---|---|
| lbfactor | 70 | 30 |
| lbstatus | -30 | 30 |
| lbstatus | 40 | -40 |
| lbstatus | 10 | -10 |
| lbstatus | -20 | 20 |
| lbstatus | -50 | 50 |
| lbstatus | 20 | -20 |
| lbstatus | -10 | 10 |
| lbstatus | -40 | 40 |
| lbstatus | 30 | -30 |
| lbstatus | 0 | 0 |
| (repeat) | ||
Apr�s 10 distributions, la planification se r�p�te et 7 a sont s�lectionn�s avec 3 b intercal�s.