Scaling up the ASP.NET session state server

Question

Scenario:

The website is hosted on three servers using IIS on each.

All three servers are clustered using the network load balancing software that comes with Windows Server 2003.

All three sites are configured to store the session state on a separate server that has been designated as a "state server".

I have been asked to scale up the "state server". Is there a way that I can have more than one state server and synchronize state between them, so if one of the state servers goes down the others will be able to serve the state information?

Answer 1

We use Scale Out State Server for this where I work, and it does the job wonderfully and is dead simple to set up. I understand Microsoft is also working on a similar product called Velocity, but I don't have any experience with it.

The only downside to SOSS is that you've got to pay for it - but I've had nothing but great experiences interacting with their sales and support team. If you end up licensing, do me a favor and let them know that Daniel from Gratis sent you ;)

Answer 2

I'd go for memcached. You could set it up on each of the web servers and then you could scale it with each new web server you add. I've found a couple of clients on codeplex before.

Answer 3

You are looking for a distributed caching technology. Microsoft Velocity is one that has examples posted by Microsoft for replacing the default ASP.NET Session state with Velocity that it can be distributed. There are other caching providers such as Memcache.

Edit: Updating this answer for info more relevant to current time, this type of functionality is built into Windows Azure with the AppFabric product. Some brief information about this can be seen here: Windows Server and Azure AppFabric virtual launch May 20th

Answer 4

The session database on an SQL server can be easily scaled out with little code & configuration changes. You can stick asp.net sessions to a session database and irrespective of which web server in your farm serves the request, your session-id based sql state server mapping works flawless. This is probably one of the best ways to scale out the ASP.NET Session state using SQL server. For more information, read the link

True Scaleout model for session state

Answer 5

The best thing you can do is avoid the state server completely.

The only way to really scale session state is to avoid completely depending on a session storage backend (in-proc, sql, mongo or whatever).

If session data is small enough to fit (which usually is in most applications) in the headers of the request, it should be kept inside a cookie (signed!) and move back and forth with the requests themselves. No single point of failure, no scaling issues, no need to size memory or cpu requirements.

JWT is a know standard that can be used for that, this post here points to a JWT based ASP.Net session state provider:

http://www.drupalonwindows.com/en/content/aspnet-session-state-scaling-and-performance-issues