httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jim Jagielski <...@jaguNET.com>
Subject Re: mod_proxy/mod_proxy_balancer bug
Date Thu, 23 Apr 2009 12:45:41 GMT

On Apr 22, 2009, at 5:16 AM, jean-frederic clere wrote:

> Rainer Jung wrote:
>> On 20.04.2009 15:57, Jim Jagielski wrote:
>>> On Apr 17, 2009, at 4:28 PM, 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 have some ideas on the "soft start" when a errored-out worker
>>> returns (or when a new worker is added *hint* *hint*) that I've
>>> been playing with. The main thing, for me at least, is low overhead,
>>> even if it means sacrificing accuracy to the nth decimal place...
>>> I used to think aging was not something we wanted to do in
>>> mod_proxy, but mostly it was based on complex aging, and the
>>> overhead associated with that. But I have some ideas there as
>>> well.
>>>
>>> The main thing I've been working on is trying to do all these
>>> things in trunk in a way that is "easily" backportable to 2.2...
>> So that makes my answer to JFC partially obsolete. Sorry I read your
>> post later.
>
> Yep I have also experimented in the area... We need to do something.
>

+1... Maybe I'll branch off a 2.2-proxy branch as a sandbox to play
around in... Then we can front-port to trunk and use the sandbox as
the backport source :)


Mime
View raw message