httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From jean-frederic clere <jfcl...@gmail.com>
Subject Re: mod_proxy / mod_proxy_balancer
Date Tue, 05 May 2009 20:41:48 GMT
Jim Jagielski wrote:
> 
> On May 5, 2009, at 3:02 PM, jean-frederic clere wrote:
> 
>> Jim Jagielski wrote:
>>> On May 5, 2009, at 1:18 PM, jean-frederic clere wrote:
>>>> Jim Jagielski wrote:
>>>>> On May 5, 2009, at 12:07 PM, jean-frederic clere wrote:
>>>>>> Jim Jagielski wrote:
>>>>>>> On May 5, 2009, at 11:13 AM, jean-frederic clere wrote:
>>>>>>>>
>>>>>>>> I am trying to get the worker->id and the scoreboard associated

>>>>>>>> logic moved in the reset() when using a balancer, those workers

>>>>>>>> need a different handling if we want to have a shared 
>>>>>>>> information area for them.
>>>>>>>>
>>>>>>> The thing is that those workers are not really handled
>>>>>>> by the balancer itself (nor should be), so the reset() shouldn;'t
>>>>>>> apply. IMO, mod_proxy inits the generic forward/reverse workers
>>>>>>> and m_p_b should handle the balancer-related ones.
>>>>>>
>>>>>> Ok by running first the m_p_b child_init() the worker is 
>>>>>> initialised by the m_p_b logic and mod_proxy won't change it later.
>>>>>>
>>>>>>>
>>>>> Yeah... a quick test indicates, at least as far as the perl
>>>>> framework is considered, changing to that m_p_b runs 1st in child_init
>>>>> results in normal and expected behavior.... Need to do some more
>>>>> tracing to see if we can copy the pointer instead of the whole
>>>>> data set with this ordering.
>>>>
>>>> I have committed the code... It works for my tests.
>>>>
>>> Beat me to it :)
>>> BTW: I did create a proxy-sandbox from 2.2.x in hopes that a
>>> lot of what we do in trunk we can backport to 2.2.x....
>>
>> Yep but I think we should first have the reset()/age() stuff working 
>> in trunk before backporting to httpd-2.2-proxy :-)
>>
> 
> For sure!!
> 
> BTW: it seems to me that aging is only really needed when the 
> environment changes,
> mostly when a worker comes back, or when the actual limits are changed
> in real-time during runtime. Except for these, aging doesn't seem to
> really add much... long-term steady state only gets invalid when the
> steady-state changes, after all :)
> 
> Comments?
> 
> 

I think we need it for few reasons:
- When a worker is idle the information about its load is irrelevant.
- Being able to calculate throughput and load balance using that 
information is only valid if you have a kind of ticker.
- In some tests I have made with a mixture of long sessions and single 
request "sessions" you need to "forget" the load caused by the long 
sessions.

The next question is how do we call the ageing?
- Via a thread that calls it after an elapsed time.
- When there is a request and the actual time is greater than the time 
we should have call it.

Cheers

Jean-Frederic

Mime
View raw message