Документ взят из кэша поисковой машины. Адрес
оригинального документа
: http://www.arcetri.astro.it/manual/en/mod/mod_lbmethod_byrequests.html
Дата изменения: Fri Nov 20 00:43:56 2015 Дата индексирования: Sun Apr 10 11:07:49 2016 Кодировка: Поисковые слова: п р п р п р п р п р п р п |
Apache HTTP Server Version 2.4
Description: | Request Counting load balancer scheduler algorithm for mod_proxy_balancer |
---|---|
Status: | Extension |
Module Identifier: | lbmethod_byrequests_module |
Source File: | mod_lbmethod_byrequests.c |
Compatibility: | Split off from mod_proxy_balancer in 2.3 |
This module does not provide any configuration directives of its own.
It requires the services of mod_proxy_balancer
, and
provides the byrequests
load balancing method..
This module provides no directives.
Enabled via lbmethod=byrequests
, the idea behind this
scheduler is that we distribute the requests among the
various workers to ensure that each gets their configured share
of the number of requests. It works as follows:
lbfactor is how much we expect this worker to work, or the workers' work quota. This is a normalized value representing their "share" of the amount of work to be done.
lbstatus is how urgent this worker has to work to fulfill its quota of work.
The worker is a member of the load balancer, usually a remote host serving one of the supported protocols.
We distribute each worker's work quota to the worker, and then look which of them needs to work most urgently (biggest lbstatus). This worker is then selected for work, and its lbstatus reduced by the total work quota we distributed to all workers. Thus the sum of all lbstatus does not change(*) and we distribute the requests as desired.
If some workers are disabled, the others will still be scheduled correctly.
for each worker in workers
worker lbstatus += worker lbfactor
total factor += worker lbfactor
if worker lbstatus > candidate lbstatus
candidate = worker
candidate lbstatus -= total factor
If a balancer is configured as follows:
worker | a | b | c | d |
---|---|---|---|---|
lbfactor | 25 | 25 | 25 | 25 |
lbstatus | 0 | 0 | 0 | 0 |
And b gets disabled, the following schedule is produced:
worker | a | b | c | d |
---|---|---|---|---|
lbstatus | -50 | 0 | 25 | 25 |
lbstatus | -25 | 0 | -25 | 50 |
lbstatus | 0 | 0 | 0 | 0 |
(repeat) |
That is it schedules: a c d a c d a c d ... Please note that:
worker | a | b | c | d |
---|---|---|---|---|
lbfactor | 25 | 25 | 25 | 25 |
Has the exact same behavior as:
worker | a | b | c | d |
---|---|---|---|---|
lbfactor | 1 | 1 | 1 | 1 |
This is because all values of lbfactor are normalized with respect to the others. For:
worker | a | b | c |
---|---|---|---|
lbfactor | 1 | 4 | 1 |
worker b will, on average, get 4 times the requests that a and c will.
The following asymmetric configuration works as one would expect:
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) |
That is after 10 schedules, the schedule repeats and 7 a are selected with 3 b interspersed.