On Thu, Aug 13, 2009 at 05:21:28AM -0400, John Lauro wrote:
> The biggest issue probably is that you are using cookies that will tie a
> client to a server. For me, I noticed it often takes over 3 days to get the
> first 80% of the traffic off if I mark a server as soft down as people never
> reboot or close the browser. If you have more random traffic and less
> regular visitors it might not take so long.
It will depend on the type of traffic and application in fact. A site such as a forum or similar where people never go away can indeed stick users for a long time to a server. But after all, that's the precise reason you're using cookies in the first place.
A site where people consult some information (eg: online sales) will not have this behaviour because people don't stay that long.
> Leastconn is more accurate for how the servers look at that moment in time.
Leastconn is only accurate for long sessions. In fact, it's still accurate enough for short sessions because it does roundrobin between servers at an equal number of sessions, but it should really be avoided for short sessions such as HTTP. It's fine for SQL, LDAP, TSE, ... though.
> However, it does not take into account all clients that closed the session
> but have a cookie for a server, and it's only used for clients that don't
> already have a cookie. Round robin or one of the other methods might work
> better, but it can take close to a week for you to know if it's any better
> or not as a large number of your users are already tied to a specific server
> with a cookie. I used to use roundrobin and I think it worked better with
> cookies, but currently I don't have any traffic requiring cookies and so
> leastconnn has been working better.
Anyway, given the differences between the two counters, I don't even think the LB algo is the cause. We don't have the other columns, but I'd suspect that one of the servers is regularly offline due to failed health-checks while the other one is not.
Regards,
Willy
Received on 2009/08/13 22:40
This archive was generated by hypermail 2.2.0 : 2009/08/13 22:45 CEST