ASP.Net Session State

If you do a search on the web for "ASP.NET Session State", you would probably get those  links from MSDN

http://msdn.microsoft.com/en-us/library/ms178581.aspx and
http://msdn.microsoft.com/en-us/library/ms178586(v=vs.100).aspx

Basically you are offered with 3 options:

1.      In Process
2.      State Server
3.      SQL/Server

Beyond that, you are on your own.

Well, In a typical enterprise system, server farm or some kind of load balancing are considered as typical configuration in most of the deployment environment. Let's look at each of these options in the context of service farm.

1)      In Process: yes, it is fast, but the session does not go beyond its own server, when a server is down (scheduled or unscheduled), so are these sessions with it. Yes, Sticky IP load balancer can reduce the negative impact of it, but when a server is down, these sessions with that server are also gone. Which may comprise the user experience for those with active sessions with the system. Secondly, "stickiness" offered by the load balancer could generate some kind uneven load among server behind the load balancer.  It is clearly not a preferred choice for enterprise web application.
2)      State Server:  the difference between state server and in process option is that in state server case, the state server is running its own process. We could configure your ASP.NET app in each server to use the state server in their respective servers, you could also configure them to use a shared state server instance. In the first configuration, it is the same as in process, when a server is down, all the active sessions are gone with it. In the second configuration, we achieved mobility of the session among member servers. So that we do not require the load balancer to provide "Sticky IP" balancing, but it offers a bigger problem, "Single Point of Failure" .Because in this configuration, when the computer host the State Server is down or the State Service on the computer is down, the entire site is down, regardless how many computers are behind the load balancer. It is also not a preferred choice for enterprise web application.
3)      SQL/Server: it addressed the SPoF issue posed by state server solution, but there are 3 issues with its solution: 1)  if the SQL/Server is down, so is the entire system. 2) To address that issue, you would have to configure a cluster SQL Server, but it is much expensive than any other solution. 3) Most of public facing web sites are hosted in DMZ zone. And you seldom see infrastructure architects allow a SQL/Server (let alone cluster SQL/Server ) to be installed in DMZ zone. So even though it is a possible solution, but in most of cases it not feasible.


 So the industry is looking for some kind of state management solution with following characteristics:

1)      fault tolerance
2)      session mobility
3)      high performance
4)      low cost


Well, there are many solutions on the market as of today, some are cloud implementation, and some are for in-promise implementation. In this article, I will pick one in each category as a form of introduction


1.      N-cache, In-Memory Distributed Cache for .NET

The following link offers the product overview on NCache, http://www.alachisoft.com/ncache/,  as indicated in the title, it is In-Memory Distributed Cache for .NET. it is running in the memory of each member servers, so it is as fast as state server. It is distributed, the sessions created in one member server get replicated to other member servers, so it achieved session mobility. As it is kind of plug and play, no code changes is involved, all we need are 1) install the product 2) change the web.config file to use the service.  In term of cost, it is a product offered by Alachisoft, you can download the product from its site and give it a try. I could not image it is more expensive than the cost of a cluster SQL/Server Box, not even a faction of it.


2.      Microsoft Azure Cache Cloud implementation

Not too long ago, Microsoft Azure launched a Cache service in data service category. The following link provided step by step instruction on how to implement Session state using Azure cache. http://azure.microsoft.com/en-us/documentation/articles/web-sites-dotnet-session-state-caching/ , I personally created a cache in my Azure and use it in my web site hosted in Azure, it works well for me... however, as my site is "Shared" site, not even single server side, so I could not verify the effect when the site is running behind the load balancer. But form programming point of view, it is very simple. You will get it done within an hour.

From cost point of view, for a cache with capacity up to 128M and scale to up to 8 units, it is about $12.5 a month. At the high end, you can get 10 caches with the capacity up to 5G and scale to up to 30 units with high availability and notification feature at $200 a month.


In conclusion, both solution eliminated "single Point of Failure" in Session State management, offered session mobility , high performance and low cost.