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.