VietMX Staff asked 3 years ago
If you must use server-local session state (e.g. shopping carts), sticky sessions are definitely the way to go. Your load balancer should be able to look at HTTP cookies (not only IP address) to determine stickiness, since IP addresses can change during a single session (e.g. docking a laptop between a wired and wireless network).
Pros:
- it’s easy to implement – no app changes required.
- better utilizes local RAM caches (e.g. look up user profile once, cache it, and can re-use it on subsequent visits from same user)
Cons:
- if the server goes down, session is lost. (note that this is a con of storing session info locally on the web server– not of sticky sessions per se). if what’s in the session is really important to the user (e.g. a draft email) or to the site (e.g. a shopping cart) then losing one of your servers can be very painful.
- depending on “sticky” implementation in your load balancer, may direct unequal load to some servers vs. others
- bringing a new server online doesn’t immediately give the new server lots of load– if you have a dynamic load-balancing system to deal with spikes, stickiness may slow your ability to respond quickly to a spike. That said, this is somewhat of a corner case and really only applies to very large and sophisticated sites.
- if you have relatively few users but a single user’s traffic can swamp one server (e.g. complex pages with SSL, AJAX, dynamically-generated images, dynamic compression, etc.), then stickines may hurt end-user response time since you’re not spreading a single user’s load evenly across servers. If you have a lot of concurrent users, this is a non-issue since all your servers will be swamped
