mod_lbmethod_byrequests 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 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.

mod_proxy mod_proxy_balancer
Algorithme d'attribution des requêtes

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.