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 factor
Si 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.