Sticky Sessions vs Non-Sticky Sessions - 我的博客 - ITeye技术网站
Non-Sticky Session
The non-sticky configuration produces the most fair balancing.
All the sessions are managed by all the servers that receives request for that session. But the session is cleared, ie, the attributes of the session are only in the local session while the request lives in the container, once the session is unlocked the attributes are cleared.
Error conditions in the repo are immediately detected (session is always read and written, no caching is done).
This configuration needs the server to lock/unlock sessions and that operations represents some performance degradation (there are more operations performed and more complex).
Locking can produce some weird behaviors if the application sends several requests at the same time or in parallel (usually applications that uses web-services a lot). In normal applications (one request, one page) this effect is meaningless.
Sticky Session
Non-Sticky Session
Sticky Session
There are two main downsides:
- Your load isn't evenly distributed.
- Proxies conglomerate users into single IP's, all of which would get sent to a single server.
