.Net Sessions in Load Balanced WebFarms

Introduction
This document is aimed to write some fact about session issue in Clustering scenario.  Web cluster is mostly implemented using web-farms. The following facts are based on the project based experiences which author has gained.

1. Session Issue
Session can not be managed in a web farm implementation because the load balancer can route the traffic from the same requester to another web server based on several criteria. Few criteria are web/app server's current load, amount of memory remaining, etc.
The moment second or subsequent web page request is routed to another web server by the load balance server (e.x - F5) , your site will stop working and your data may be lost.

Find below some facts
1. In Web Farm, there are at least following servers.
Once load balancer
Two or more Web Servers
Once or more App Servers
One or more database servers

2. By default, in a load-balanced web farm implementation, it is not guaranteed that request from the same client will always be severed by the same web server from the Farm. It happens due the fact that the request can be routed to any available web server by the load balancer. F5 is an example of good load balance server. This is heavenly used by clients who has very sensitive type of data, like Banking Clients.

3. In this case, the server sessions which were created and stored on web server will not be available to another web server, if the same user requests/submits a web page and he will get error.

4. So in web farm implementation,  server-based session concepts can not be used without any special arrangements.

5. Though in several organization, for web farm implementation, the default configuration of load balancer is such a ways that the load balance always sent the client request to the same web server for first 300 seconds from the time of first request. Several Banking clients keeps this setting as it is. Note that is a very important concept to remember. It can solve a lot of issues after your first time deployment of any code in production.

Relevant AD	This ad may be helpful, if relevant to your search.

Alternatives:  .Net web in LoadBalanced scenario in Web-farm Implementation

Option  A :    Session State alternatives (changes at code level)

1.     Use Cookies to preserve data between different calls.

a.       Cookies are more scalable option than using sessions. Since all data are stored on client machine, memory on server remains free for other tasks. Instead of spending server resources like memory or database, ASP.NET will distribute data to visitors' computers.

2.       ASP.NET ViewState

a.     ASP.NET ViewState state stores information in page's HTML code, as hidden field named __VIEWSTATE. ViewState is also very scalable solution. Like in case when using cookies, information are stored on client side and don't load on server.

b.    Unlike Session state, ViewState is designed to preserve data between post backs on same page. You can't, at least by default, send data between pages using ViewState. There are some workarounds, you can, for example place some data to ViewState and then use Server.Transfer to load the second page. In this case, ViewState variables will be visible on second page so you practically transferred data between different pages using ViewState

3.       Use hidden fields

a.     You can place standard HiddenField control on web form and use its Value property to store user's data

4.       Query strings

a.     Query strings were common option to send data between pages. Even ASP.NET session state uses query string variable in URL if Cookieless parameter is set to true. So, query strings work if user is disabled cookies in browser.

b.      Disadvantage of query strings is that you can't transfer a lot of data on this way. I think your application uses session to temporarily store preventative data type and hence Query string is suitable option for you.

5.       Profile properties

a.  Profile data remains after visitor leaves website and session expires. Because data are stored in Sql Server database by default, they are not affected on ASP.NET restart or even IIS restart.

Note: If your application needs to persist some sensitive date across multiple page loads, even session variables are not all a secure mechanism to store these data because several viral or trojan attack can read this session data from server’s memory. The most reliable way to keep user's information across sessions is to store them to database on server. You can do it manually, but it is usually more efficient to use Profile properties.

Option  B :    Change at Infrastructure level

1.       New SQL Session state sever
2.       New ASP.Net Out Proc Server

For both of the above, the network/server engineer must have one more/shared computer hardware which will serve as common location to store sessions of each web server present in the web farm. I think we don’t have this kind of infrastructure setup either in QA or Production environment as of now. If needed , it will take a lot of time and money and of course several level of approvals.

Conclusion : I have generally seen (where sticky session is not enable on load balancer) that Option A.2, A.3 and A.4 are used simultaneously across the whole application starting right from coding.

Did you like this post ? Do leave a comment or share with your Facebook friends. This will give me more reasons to write such posts.