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? Does mod_cluster provide yet another approach top to bottom (separate than mod_jk and mod_proxy/mod_proxy_ajp)? 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.

--
Jess Holle

Reply via email to