On 06.05.2009 10:35, Jess Holle wrote: > Rainer Jung wrote: >> In most situations aplications need stickyness. So balancing will not >> happen in an ideal situation, instead it tries to keep load equal >> although most requests are sticky. >> >> Because of the influence of sticky requests it can happen that >> accumulated load distributes very uneven between the nodes. Should the >> balancer try to correct such accumulated differences? >> Other applications are memory bound. Memory is needed by request >> handling but also by session handling. Data accumulation is mor >> eimportant here, because of the sessions. Again, we can not be perfect, >> because we don't get a notification, when a session expires or a user >> logs out. So we can only count the "new" sessions. This counter in my >> opinion also needs some aging, so that we won't compensate historic >> inequality without bounds. I must confess, that I don't have an example >> here, how this inequality can happen for sessions when balancing new >> session requests (stickyness doesn't influence this), but I think >> balancing based on old data is the wrong model here too. >> > 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. > 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. > 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. Regards, Rainer
