Pros and cons of affinity load blancing session sticking strategy?

Question

One approach to high scalability is to use network load balancing to share the processing load between multiple servers.

One of the problems this approach presents is where the state aware servers are maintaining the state of the user in a “session”.

One solution to this problem is a “sticky session” (for example, “session affinity”), where each user is assigned to one server, and his state data is stored on this server exclusively for the entire session.

What are the pros and cons of a sticky session approach? Do you use it, and if you are satisfied with it?

Answer 1

Pros:

• easy - no application changes required.
• it is better to use local RAM caches (for example, view the user profile once, cache it and reuse it on subsequent visits to the same user).

Minuses:

• If the server is down, the session is lost. (note that this message is about storing session information locally on a web server - not from sticky sessions per se). if what’s really important for the user in the session (for example, an email project) or on a website (for example, in a shopping cart), losing one of your servers can be very painful.
• depending on the sticky implementation in your load balancer, it can direct unequal load on some servers and others.
• bringing a new server to the network does not immediately give a new server a large load - if you have a dynamic load balancing system to handle bursts, stickiness can slow down your ability to respond quickly to a burst. However, this is a somewhat angular case and really only applies to very large and complex sites.
• If you have relatively few users, but one user traffic can load one server (for example, complex pages with SSL, AJAX, dynamically generated images, dynamic compression, etc.), then the sheets can damage the response time of end users, since you "does not evenly distribute the load per user on all servers. If you have many simultaneous users, this is not a problem, since all your servers will be loaded!

But if you must use the state of the local server session, then sticky sessions are definitely suitable for you - and even if you do not use the local session state on the server, stickiness has advantages when it comes to using the cache (see above). Your balancer should be able to view HTTP cookies (and not just the IP address) to determine stickiness, since IP addresses can change in one session (for example, connecting a laptop between a wired and wireless network).

Even better, do not use session state on the web server at all! If the session state is very painful to lose (for example, shopping carts), store it in a central database and periodically clean up old sessions. If the session state is not critical (for example, the username / URL of the avatar), then paste it into the cookie - just make sure that you do not drag too much data into the cookie.

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