Dan, > The problem is that it appears that AOL will randomly assign an IP > address to every request a user sends. So a user could end up going > to both servers.
Yup. AOL is feisty like that. > The load balancer makes the decision to go to app server 1 (app1) or > app server 2 (app2) based on IP address - once a request comes in > from one source IP, all future requests (for some period of time) go > to the same server. How does the lb decide where you go for all requests after the first one? Typically, the session id is sniffed from the URL or cookie and the lb maintains a table of mappings that expires after some time. It doesn't sound like that's happening here. It looks like your "first time" behavior is actually happening for every request. Can you confirm how your lb works in your setup? > Although this approach seems to work, it also has some problems, and > I was wondering if others had encountered this problem, and if there > was a "standard" solution. One option is session sharing (or clustered sessions?). I have forgotten what they are called but basically all the servers share session data, so it doesn't matter which server you eventually go to. If you don't have a lot of data going into the session, I would imagine that it isn't too chatty on the backend. When consulting for [a large robber baron in the SSL cert racket], their setup was to actually divert all of their AOL customers away from the main cluster and onto a separate machine. I think it was a single-box setup for the AOLers, based upon the actual load that AOLers represented. I would imagine that you could setup session sharing among a cluster of AOL-specific servers if you wanted to do something like that. Then only the AOLers would suffer from the (somewhat) poorer performance you'd get with session sharing. -chris
signature.asc
Description: OpenPGP digital signature
