Rainer Jung wrote:
The same type of balancing decision algorithm was part of mod_jk between
1.2.7 and 1.2.15. I always had problems to understand, how it exactly
behaves in case some workers are out of order. The algorithm is
interesting, but I found it very hard to model its mathematics into
formulas.
We finally decided to switch to something else. For request, traffic or
session based balancing we do count items (requests, bytes or new
sessions), and divide the counters by two once a minute. That way load
that happened in the past does count less.
Furthermore a worker that was dead or deactivated some time gets the
biggest current load number when being reactivated, so that it starts a
smooth as possible.
I expect porting this to mod_proxy in trunk will be easy, but I'm not
sure what experience others have with the fairness of balancing in case
you add dynamics to the workers (errors and administrative downtimes).
I'd be /_very_ /interested in such a port to mod_proxy_balancer -- in
2.2.x in my case. Any help/pointers/assistance would be appreciated. I
could apply such a change as a patch to just my version, but I'd be a
lot more interested in getting 2.2.x as a whole to a better place and
not having to maintain my own fork of things.
I get a strong impression that others haven't really pushed
mod_proxy_balancer in this area.
Overall having solid mod_proxy_balancer functionality obviously benefits
more than just AJP and I like the idea of mod_proxy_ajp. That said, if
mod_jk is going to move ahead and mod_proxy_ajp become a backwater at
some point I'll need to move back to mod_jk, though I'd really want the
ability to gracefully throttle requests in mod_jk first. [When mod_jk
runs out of connections it gives a 503. mod_proxy can queue up requests
instead.]
--
Jess Holle
