Sticky Session

An ASP.NET State is used to keep data across a sequence of user requests to the server.

This Session State is usually maintained from the first user request until a specific period after the user's last request, usually around 20 minutes.

If your application is running on only one server, you can use the standard ASP.NET Session State without any problems.

 

However, if you want your application to run in a server-cluster/server-farm (I.e. More than one server), then you need to make sure that either:

 

A.      Session State is available from all the servers in the farm (State Server / SQL Server) - Out-of-Proc Session State

B.      Use "Sticky Sessions" feature of your Load-Balancer - In-Process Session State

 

Both of these approaches has its own scalability problems.

Both of them force you into a Single-Point-Of-Failure scenario and they're also Not Very Scalable because all the load of accessing the Session State is shifted to one server.

 

 

Option B):

 

Read This - Link

 

In the In-Proc Session mode, the session has "affinity" with the server.  I.e. Session Id only exists in the memory of that one server to which the first request hits.

That means that if www.mydomain.com is the first server the user ever hits, the user will get an ASPSESSIONID that only exists in the memory of that one server. 

 

To guarantee the user gets back to his/her session on the next HTTP Request (when you have more than one server), - Requires using "Sticky Connections" or Node-Affinity feature of your Load-Balancer.

I.E. if you want your application to run in a server-cluster/server-farm, then you need to make sure that you use "Sticky Sessions" feature of your load-balancer.

 

When you load balance your ASP.Net application(or any web application), the sticky session ensures that all the subsequent request will be send to the server who handled the first request corresponding to that request.  

 

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 request 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.

 

Better Solution:

 

The answer to all of this is to have Session State Truly Clustered. This way, it does not matter on which server the session was actually created because the session lives in the entire cluster.

The user request can then be forwarded by the load-balancer to the most appropriate server. This approach is also highly scalable and there is no single point of failure.

Sticky sessions work with the load balancer to improve efficiency of Persistent Sessions in a clustered configuration. In a clustered configuration, the load balancer sends requests to multiple backend Resin servers. Each session has an owning Resin server and a backup Resin server. The load balancer will send a session's request to the owning server or to the backup if the owning server is not available.

The association of a session with a backend server is called "Sticky Sessions".

 

Because the load balancing occurs before any interpretation of the Virtual Host or Web Application, it's a <server> configuration variable, with the <session-cookie> tag.

 

Reference: Link

 

Thanks & Regards,

Arun Manglick,

Project Manager - Forecasting
Mobile: 9158041782| 9850901262| Desk Phone: +912040265348 | http://www.synechron.com

SYNECHRON -
- 4,000+ professionals globally.
- USA | Canada | UK | The Netherlands | UAE | India | Singapore | Hong Kong | Japan