Serveur HTTP Apache 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
.
Activé via lbmethod=byrequests
, ce planificateur a
é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.