Home‎ > ‎Computer Bloggers‎ > ‎

Webfarm and Sessions

I am going to write some fact about session issue in Clustering senario.  Web cluster is mostly implemented using webfarms.
The following facts are based on my project based experiences which I got in last few weeks.
1. Sesssion Issue
Session can be managed in web farm implementition bucease the load balancer can route the trafic from the same rquester to another web server based on several criteria. Few criterias are servr loads, less memory , etc.
The moment second or subsequet web page request is routed to another web server by the load balance, your site will stop workign 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 sererers
    One or more database servesr
2. By default, the in loadbalnced web farm implementation, it is not garenteed that request from the same client will always be servered by the same web server from the Farm. It happed due the fact that the request can be routed to any available web server by the load balance.
3. In this case, the server sessions which was created and stored on on web server will not be available to anothe web server, if the same user requests/submits a web page and he will get error.
4. So in web farm implemention,  server based session concepts are not used.
5. Thought in several organization, for  webfarm implementation,  the default configuration on load balancer is such a ways that the load balance always sent the cleint requet to the same web server for first 300 seconds from the time of first reqest.
Design alterantives of ASP.Net web applicaiton in LoadBalanced senario in WebFarm

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 trozan 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 ofcourse 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.