httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From jean-frederic clere <>
Subject Re: mod_proxy / mod_proxy_balancer
Date Wed, 06 May 2009 12:35:44 GMT
Jess Holle wrote:
> Rainer Jung wrote:
>>> An ability to balance based on new sessions with an idle time out on
>>> such sessions would be close enough to reality in cases where sessions
>>> expire rather than being explicitly invalidated (e.g. by a logout).
>> But then we end up in a stateful situation. This is a serious design
>> decision. If we want to track idleness for sessions, we need to track a
>> list of sessions (session ids) the balancer has seen. This makes things
>> much more complex. Combined with the non-ability to track logouts and
>> the errors coming in form a global situation (more than one Apache
>> instance), I think it will be more of a problem than a solution.
> The more I think about this the more I agree.
>  >From the start I preferred the session/health query to the back-end 
> with a time-to-live, on further consideration I *greatly* prefer this 
> approach.
>>> Of course that redoes what a servlet engine would be doing and does so
>>> with lower fidelity.  An ability to ask a backend for its current
>>> session count and load balance new requests on that basis would be
>>> really helpful.
>> Seems much nicer.
> Agreed.
>>> Actually this could and should be generalized beyond active sessions to
>>> a back-end health metric.  Each backend could compute and respond with a
>>> relative measure of busyness/health and respond and the load balancer
>>> could then balance new (session-less) requests to the least busy / most
>>> healthy backend.  This would seem to be *huge* step forward in load
>>> balancing capability/fidelity.
>>> It's my understanding that mod_cluster is pursuing just this sort of
>>> thing to some degree -- but currently only works for JBoss backends.
>> Yes, I think the counter/aging discussion is for the baseline, i.e. when
>> we do not have any information channel to or from the backend nodes.
>> As soon as mod_cluster comes into play, we can use more up-to-date real
>> data and only need to decide how to interprete it and how to interpolate
>> during the update interval.
> Should general support for a query URL be provided in 
> mod_proxy_balancer?  Or should this be left to mod_cluster?

Can you explain more? I don't get the question.

>  Does 
> mod_cluster provide yet another approach top to bottom (separate than 
> mod_jk and mod_proxy/mod_proxy_ajp)?

Mod_cluster is just a balancer for mod_proxy but due to the dynamic 
creation of balancers and workers it can't get in the httpd-trunk code 
right now.

>  It would seem nice to me if mod_jk 
> and/or mod_proxy_balancer could do health checks, but you have to draw 
> the line somewhere on growing any given module and if mod_jk and 
> mod_proxy_balancer are not going in that direction at some point 
> mod_cluster may be in my future.

Cool :-)



View raw message