Jim Jagielski wrote:
On May 6, 2009, at 4:35 AM, Jess Holle wrote:
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. Whether this ability is buried into AJP, for
instance, or is simply a separate request to a designated URL is
another question, but the latter approach seems fairly general and
the number of such requests could be throttled by a time-to-live
setting on the last such count obtained.
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.
The trick, of course, at least with HTTP, is that the querying of
the backend is, of course, a request, and so one needs to worry about
such things as keepalives and persistent connections, and how long
do we wait for responses, etc...
That's why oob-like health-and-status chatter is nice, because
it doesn't interfere with the normal reverse-proxy/host logic.
An idea: Instead of asking for this info before sending the
request, what about the backend sending it as part of the response,
as a response header. You don't know that status of the machine
"now", but you do know the status of it right after it handled the last
request (the last time you saw it) and, assuming nothing else touched
it, that status is likely still "good". Latency will be an issue,
of course... Overlapping requests where you don't have the response
from req1 before you send req2 means that both requests think the
server is at the same state, whereas of course, they aren't, but it
may even out since req3, for example, (which happens after req1 is done)
thinks that the backend has 2 concurrent requests, instead of the 1
(req2) and so maybe isn't selected... The hysteresis would be interesting
to model :)
There's inherent hysteresis in this sort of thing.
Including health information (e.g. via a custom response header) on all
responses is an interesting notion.
Exposing a URL on Apache through which the backend can push its health
information (e.g. upon starting a new session or invalidating a session
or detecting a low memory condition) also makes sense.
If these do not suffice a watchdog thread (as in mod_jk) could do
periodic health checks on the backends in a separate thread or requests
could pre-request health information for a backend if that backend's
health information is sufficiently old.
There's lots of possibilities here.
--
Jess Holle
