Friday, 25 April 2014

To use sticky sessions with the load balancer or not?

In sticky Sessions, all your requests are directed to the same physical web server while in case of non-sticky load balancer May choose any web server to serve your requests.

Let's forget the sticky session for a bit and discuss the flow of how the non-sticky session works.

If your website is served by multiple web servers who sit behind a load balancer, the load balancer decides which Actual web-server each request should go to. For example, if there are 2 web servers, web 1 and web 2 behind the Load balancer, it is possible that http://www.mywebsite.com/default.aspx is served from web 1 and http://www.mywebsite.com/login.aspis served from web 2.

Now, if the requests are being served from two different servers, each server has created a session object for you and because these session objects sit on two independent boxes, there's no direct way of one knowing what is there in the session object of the other. In order to synchronize between these server sessions, you may have to use database to maintain the session information. Which is not a good idea and Now, comes the role of sticky-session.

If the load balancer is instructed to use sticky sessions, all of your interactions will occur with the same physical server, even though other servers are present. Thus, your session object will be the same throughout your entire interaction with this website.

Damn it! Is it an alternative of database session management when the website is in load balancing? Well, I'm not able to figure it out. But I would say not to use sticky session.

The problem with sticky sessions is that they limit your application scalability because the load balancer is unable to truly balance the load each time it receives requests from a client. With sticky sessions, the load balancer is forced to send all the requests to their original server where the session state was created even though that server might be heavily loaded and there might be another less-loaded server available to take on this request. This is really bad when your website is being used by millions of users a day.

I'm still trying to figure out either this new feature is a breakthrough for the load balancing or just an alternative we can use with In-proc session state in a large-scale application. I may write a next blog if I can conclude the sticky session.


I have used the New Elastic Load Balancing Sticky Sessions feature of AWS, which is explained in below the link:

No comments:

Post a Comment