Pros and Cons of Sticky Session / Session Affinity load blancing strategy?

Question

One approach to high scalability is to use network load balancing to split processing load between several servers.

One challenge that this approach presents is where servers are state aware - storing user state in a "session".

One solution to this problem is "sticky session" (aka "session affinity") where each user is assigned to a single server and his/her state data is contained on that server exclusively throughout the duration of the session.

What are the Pros and Cons of the "sticky session" approach? Do you use it and if so are you satisfied with it?

Novelist

Answer 1

Pros:

• It's easy-- 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 stickiness 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!

But if you must use server-local session state, sticky sessions are definitely the way to go. Even if you don't use server-local session state, stickiness has benefits when it comes to cache utilization (see above). 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).

Even better, don't use session state on the web server at all! If session state is very painful to lose (e.g. shopping carts), store it in a central database and clear out old sessions periodically. If session state is not critical (e.g. username/avatar URL), then stick it in a cookie-- just make sure you're not shoving too much data into the cookie.

Modern versions of Rails, by default, store session variables in a cookie for the reasons above. Other web frameworks may have a "store in cookie" and/or "store in DB" option.

Phyllisphylloclade

Good anwsers! Would you please also explain a little bit more about "Your load balancer should be able to look at HTTP cookies (not only IP address) ", what do you mean more? How can the load balancer know if it is the same user? – Thundering

Web apps typically send cookies down to the client so that, when that client returns for another HTTP request, the server can recognize the same user or session. Some load balancers can look inside HTTP cookie headers to identify the user and can use that cookie value, instead of the IP address, to determine which server should receive that request. – Phyllisphylloclade

If I store the state in db/memcache, can I considered the application is stateless, while some people will say that to make a stateless app, we have to maintain the state in the client. – Thundering

@jaskey - this is a good question, I'd suggest you open a new question for that. – Phyllisphylloclade

Yeah, would you please answer here :#27016814 – Thundering

I just wanted to note the recommendation of sticking recognizable data such as a username into a cookie - though technically viable - may not be legal in some countries. Due to my knowledge, specifically the EU imposes limits of what can be stored in a cookie. – Egidio