Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
Received-SPF: neutral (athena.apache.org: 76.96.27.212 is neither permitted
 nor denied by domain of jim@jagunet.com)
Message-Id: <FBA44739-3D46-4D15-BD20-7FCDE67B9066@jaguNET.com>
From: Jim Jagielski <jim@jaguNET.com>
To: dev@httpd.apache.org
In-Reply-To: <49EEE05A.5090304@gmail.com>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v930.3)
Subject: Re: mod_proxy/mod_proxy_balancer bug
Date: Thu, 23 Apr 2009 08:45:41 -0400
References: <49E4FC52.9010207@ptc.com> <49E4FEE5.7020007@ptc.com>
 <49E8E67A.1080804@kippdata.de>
 <FAC87995-F327-4266-B9A6-943250DDFB62@jaguNET.com>
 <49EDEDF4.7030604@kippdata.de> <49EEE05A.5090304@gmail.com>


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 :)