> > Ryan Murray wrote: > > IMHO LB is not at all a long-term action - if my LB worked like current > > world stock market I'd return it to the vendor! Knowing that _over > time_ my > > "n" clustered servers did the same amount of work is not nearly as > useful as > > knowing that _right now_ my 2 servers are doing the same amount of work. > > I'm not worries about making my servers "wear out" at the same time ;) > > > It depends. If you're load balancing a new request that will end up > using a session and using sticky sessions, then this is a pretty > long-term action -- since all subsequent requests from the given session > will go to the same endpoint. If you're not dealing with sticky > sessions, then load balancing is a short-term action except in cases > where you're dealing with enormous requests or responses. > > -- > Jess Holle I certainly agree the 2 situations are different in terms the net affect on how load is added but in either case, the load on the server yesterday is irrelevant to LB decisions made today in the vast majority of applications. For many (I would guess most) real world work loads, including many stick session scenarios, having the ability to bias decisions based on "current" traffic patterns is extremely useful I would suggest if one has load patterns that are extremely variable you really want some quasi-realtime knowledge of the actual processing load on each backend to make the "ideal" LB decision for that moment. Hey maybe if you are being billed by the bandwidth of each individual node then the balancing by traffic option is the most useful but even this needs normalization over time to be relevant. In any case it's all just MHO from my humble experince! Cheers! Internal Virus Database is out-of-date. Checked by AVG. Version: 7.5.519 / Virus Database: 269.22.8/1362 - Release Date: 4/6/2008 11:12 AM --------------------------------------------------------------------- The official User-To-User support forum of the Apache HTTP Server Project. See <URL:http://httpd.apache.org/userslist.html> for more info. To unsubscribe, e-mail: users-unsubscribe@xxxxxxxxxxxxxxxx " from the digest: users-digest-unsubscribe@xxxxxxxxxxxxxxxx For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxx
|