You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Daniel Ruggeri <DR...@primary.net> on 2010/07/01 03:14:45 UTC
Re: Missing proxy_balancer feature
On 6/30/2010 7:34 AM, jean-frederic clere wrote:
> On 06/30/2010 04:17 AM, William A. Rowe Jr. wrote:
>
>> Yet again, in class another student pointed out that the Enabled/Disabled
>> choice in mod_proxy_balancer totally ignores the concept of quiescing,
>> where we are taking a server offline, but continuing to serve those
>> requests targeted by session to that server. Once the number of sessions
>> settles on something quite low, the user then takes that server offline
>> entirely and the remaining users are subjected to 'expired session' results.
>>
>> A boolean Enabled/Disabled flag doesn't address this need.
>>
>> Does anyone feel like working on this feature, since those I had
>> previously approached didn't have all that much interest, or got
>> busy with other things?
>>
>>
>>
> There are several things that requires improvements:
> 1 - The default load balancing logic doesn't work well when you restart
> a back-end node.
>
> ...
>
> Cheers
>
> Jean-Frederic
>
>
Jean-Frederic;
Can you elaborate more on point 1? I have had issues where a back
end application was not ready during a restart and throws a 503 to
Apache. Since this is a perfectly valid response to the proxied request,
Apache happily sends it along to the user. I wrote a bug (48939) and
submitted a patch that creates a configuration directive to help
mitigate this issue which is the most significant issue I have come
across during a simple back end restart. The patch is currently proposed
in STATUS, but has not received votes to go forward (or stay in STATUS).
--
Daniel Ruggeri
Re: Missing proxy_balancer feature
Posted by jean-frederic clere <jf...@gmail.com>.
On 07/04/2010 04:38 PM, Daniel Ruggeri wrote:
> On 7/1/2010 1:46 AM, jean-frederic clere wrote:
>> On 07/01/2010 03:14 AM, Daniel Ruggeri wrote:
>>
>>> On 6/30/2010 7:34 AM, jean-frederic clere wrote:
>>>
>>>> On 06/30/2010 04:17 AM, William A. Rowe Jr. wrote:
>>>>
>>>>
>>>>> Yet again, in class another student pointed out that the
>>>>> Enabled/Disabled
>>>>> choice in mod_proxy_balancer totally ignores the concept of quiescing,
>>>>> where we are taking a server offline, but continuing to serve those
>>>>> requests targeted by session to that server. Once the number of
>>>>> sessions
>>>>> settles on something quite low, the user then takes that server
>>>>> offline
>>>>> entirely and the remaining users are subjected to 'expired session'
>>>>> results.
>>>>>
>>>>> A boolean Enabled/Disabled flag doesn't address this need.
>>>>>
>>>>> Does anyone feel like working on this feature, since those I had
>>>>> previously approached didn't have all that much interest, or got
>>>>> busy with other things?
>>>>>
>>>>>
>>>>>
>>>>>
>>>> There are several things that requires improvements:
>>>> 1 - The default load balancing logic doesn't work well when you restart
>>>> a back-end node.
>>>>
>>>> ...
>>>>
>>>> Cheers
>>>>
>>>> Jean-Frederic
>>>>
>>>>
>>>>
>>> Jean-Frederic;
>>> Can you elaborate more on point 1? I have had issues where a back
>>> end
>>> application was not ready during a restart and throws a 503 to Apache.
>>> Since this is a perfectly valid response to the proxied request, Apache
>>> happily sends it along to the user. I wrote a bug (48939) and submitted
>>> a patch that creates a configuration directive to help mitigate this
>>> issue which is the most significant issue I have come across during a
>>> simple back end restart. The patch is currently proposed in STATUS, but
>>> has not received votes to go forward (or stay in STATUS).
>>>
>> That is something different the algorithm used doesn't work correctly
>> when you have long lasting sessions and the load for the past is not
>> forgotten... Basically to much load is going to the returning back-end.
>>
>> Your patch is just a work-around to the problem that httpd doesn't know
>> that the back-end shouldn't be used at that time.
>>
>> Cheers
>>
>> Jean-Frederic
>>
>>
> Jean-Frederic;
> That's a very good point and a qualm I have had with httpd for a
> while myself. As it is, the current balancer setup relies on live
> traffic to figure out if the backend is OK. Some hardware load balancers
> have the ability to "ping" backends with anything from simple TCP, HTTP
> HEAD or even SSL handshakes. Perhaps adding something like that to HTTPD
> would be the trick? The logistics of configuring such a thing might be a
> little complicated in httpd.conf... perhaps another argument that can be
> passed to ProxyPass?
> Configured like so?
> ProxyPass (or ProxySet or BalancerMember) /context
> http://someBackend:1234/context httpProbe="HEAD /context/helloWorld.do"
> probeInterval=15
>
>
> Of course, this is all conceptual - what do you think of the idea?
That is something like the worker.maintain directive of mod_jk but with
the request to do.
Something like:
maintain=time|method|[URI]
maintain=60|CPING|
maintain=60|HEAD|/context/helloWorld.do
In the case we make a request that requires the application to be able
to process it as a probe request.
> While
> this is a feature that would be *incredibly* useful, I don't think I
> have the required expertise with httpd's code to execute it.
Well that is not so easy: it requires a thread (a thread per worker) and
to update the status of the worker out of a real request which is
requires some care.
Cheers
Jean-Frederic
Re: Missing proxy_balancer feature
Posted by Daniel Ruggeri <DR...@primary.net>.
On 7/1/2010 1:46 AM, jean-frederic clere wrote:
> On 07/01/2010 03:14 AM, Daniel Ruggeri wrote:
>
>> On 6/30/2010 7:34 AM, jean-frederic clere wrote:
>>
>>> On 06/30/2010 04:17 AM, William A. Rowe Jr. wrote:
>>>
>>>
>>>> Yet again, in class another student pointed out that the
>>>> Enabled/Disabled
>>>> choice in mod_proxy_balancer totally ignores the concept of quiescing,
>>>> where we are taking a server offline, but continuing to serve those
>>>> requests targeted by session to that server. Once the number of
>>>> sessions
>>>> settles on something quite low, the user then takes that server offline
>>>> entirely and the remaining users are subjected to 'expired session'
>>>> results.
>>>>
>>>> A boolean Enabled/Disabled flag doesn't address this need.
>>>>
>>>> Does anyone feel like working on this feature, since those I had
>>>> previously approached didn't have all that much interest, or got
>>>> busy with other things?
>>>>
>>>>
>>>>
>>>>
>>> There are several things that requires improvements:
>>> 1 - The default load balancing logic doesn't work well when you restart
>>> a back-end node.
>>>
>>> ...
>>>
>>> Cheers
>>>
>>> Jean-Frederic
>>>
>>>
>>>
>> Jean-Frederic;
>> Can you elaborate more on point 1? I have had issues where a back end
>> application was not ready during a restart and throws a 503 to Apache.
>> Since this is a perfectly valid response to the proxied request, Apache
>> happily sends it along to the user. I wrote a bug (48939) and submitted
>> a patch that creates a configuration directive to help mitigate this
>> issue which is the most significant issue I have come across during a
>> simple back end restart. The patch is currently proposed in STATUS, but
>> has not received votes to go forward (or stay in STATUS).
>>
> That is something different the algorithm used doesn't work correctly
> when you have long lasting sessions and the load for the past is not
> forgotten... Basically to much load is going to the returning back-end.
>
> Your patch is just a work-around to the problem that httpd doesn't know
> that the back-end shouldn't be used at that time.
>
> Cheers
>
> Jean-Frederic
>
>
Jean-Frederic;
That's a very good point and a qualm I have had with httpd for a
while myself. As it is, the current balancer setup relies on live
traffic to figure out if the backend is OK. Some hardware load balancers
have the ability to "ping" backends with anything from simple TCP, HTTP
HEAD or even SSL handshakes. Perhaps adding something like that to HTTPD
would be the trick? The logistics of configuring such a thing might be a
little complicated in httpd.conf... perhaps another argument that can be
passed to ProxyPass?
Configured like so?
ProxyPass (or ProxySet or BalancerMember) /context
http://someBackend:1234/context httpProbe="HEAD /context/helloWorld.do"
probeInterval=15
Of course, this is all conceptual - what do you think of the idea? While
this is a feature that would be *incredibly* useful, I don't think I
have the required expertise with httpd's code to execute it.
--
Daniel Ruggeri
Re: Missing proxy_balancer feature
Posted by jean-frederic clere <jf...@gmail.com>.
On 07/01/2010 03:14 AM, Daniel Ruggeri wrote:
>
> On 6/30/2010 7:34 AM, jean-frederic clere wrote:
>> On 06/30/2010 04:17 AM, William A. Rowe Jr. wrote:
>>
>>> Yet again, in class another student pointed out that the
>>> Enabled/Disabled
>>> choice in mod_proxy_balancer totally ignores the concept of quiescing,
>>> where we are taking a server offline, but continuing to serve those
>>> requests targeted by session to that server. Once the number of
>>> sessions
>>> settles on something quite low, the user then takes that server offline
>>> entirely and the remaining users are subjected to 'expired session'
>>> results.
>>>
>>> A boolean Enabled/Disabled flag doesn't address this need.
>>>
>>> Does anyone feel like working on this feature, since those I had
>>> previously approached didn't have all that much interest, or got
>>> busy with other things?
>>>
>>>
>>>
>> There are several things that requires improvements:
>> 1 - The default load balancing logic doesn't work well when you restart
>> a back-end node.
>>
>> ...
>>
>> Cheers
>>
>> Jean-Frederic
>>
>>
> Jean-Frederic;
> Can you elaborate more on point 1? I have had issues where a back end
> application was not ready during a restart and throws a 503 to Apache.
> Since this is a perfectly valid response to the proxied request, Apache
> happily sends it along to the user. I wrote a bug (48939) and submitted
> a patch that creates a configuration directive to help mitigate this
> issue which is the most significant issue I have come across during a
> simple back end restart. The patch is currently proposed in STATUS, but
> has not received votes to go forward (or stay in STATUS).
That is something different the algorithm used doesn't work correctly
when you have long lasting sessions and the load for the past is not
forgotten... Basically to much load is going to the returning back-end.
Your patch is just a work-around to the problem that httpd doesn't know
that the back-end shouldn't be used at that time.
Cheers
Jean-Frederic