> i can't imagine any modern-day application being written requiring this,
> but i suppose i can see where it would be necessary. for example, my
> employer stores session information in a database accessable from any
> web server. i've seen shared filesystems used for this as well. but yeah
> when local disks or storing session info in webserver memory comes into
> play, i can see how that would be useful.
Many app servers are stateful, in that they require stateful information
as a shopping cart is built. Source IP could work, but with the heavier
trafficed sites, the mega-proxy issue becomes a huge problem (i've seen
it... not pretty)
> even beyond that, however, one would hope clients would use http
> keep-alive. and even beyond that, one could still use persistence on the
> ip level -- it just might not be evenly-balanced in the off chance that
> you get x number of hits from people behind the same masquerading/proxy
> gateway and little hits from other ips.
> so i still hesitate to consider that a priority. depends on
> the applications, i suppose. nevertheless, i now see your point.
> is aol that bad? aren't the ips per users still geographically dispersed?
> do they use web caches that only send requests from a small number of ips?
> i have little first-hand experience with a majority of web hits coming
> from aol. curious.
Yeah, it's a huge problem. It killed several retailers in the Xmas season
of '99. By the xmas of 2000, most of them had resolved the issue.
Also, it sounds like there are alot of scripts and other patchwork
involved for health checking, redundancy, algorythms, etc with lvs. With
the commerical products, it's just a black box you throw on a network,
with (usually) a simple configuration. In many cases, I don't have the
time to screw around with some weird scripts. I could be wrong about that
point on lvs, though.
-------------- -- ---- ---- --- - - - - - -- - - - - - -
Tony Bourke tonyIZZATvegan.net
This archive was generated by hypermail 2b30 : Fri Feb 23 2001 - 02:45:01 EST