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?

Era

Answer 1

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.

Reprisal

will Memcached actually keep the nodes in the server farm in sync? To prevent a Single Point of Failure, they would need to stay in sync, so that when items are added or removed, all nodes get notified. – Hassock

yes, the d in memcached stands for distributed, so it syncs the information across all nodes in your cluster. – Reprisal

Ah! So then, ASP.NET State Server IS interchangeable with Memcached! #291466 I was afraid Memcached wouldn't keep nodes in sync.. – Hassock

Are you sure? From the website "Memcached is a caching layer for your application. It is not designed to have any data redundancy." code.google.com/p/memcached/wiki/FAQ#How_is_memcached_redundant? – Electrolysis

Its a single cache that is distributed across multiple nodes, so no matter which node you end up connecting to you're still using the same "cache" – Reprisal

I think there's been some confusion here. memcached will distribute the hash table across as many servers as you provide, but this means that any key you push into the array will only exist on a single server, hence the d. If that server dies for whatever reason the key will die with it and a get on that key will return a blank. Though I still think it's a great solution for scaling a session store :) – Tented

Answer 2

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 ;)

Humor

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

Sacchariferous

The problem with Velocity is that is has never been officially released. It's been years now and all we have is CTP. I'm wondering what support can you expect from MS? Also the Velocity team blog has been pretty quite for a long time and this makes me wonder if MS isn't going to kill the project in a not-so-distant future. – Cristie

@Piotr Velocity was the precusor to AppFabric that is part of the Azure technology line up, cite: hanselman.com/blog/… I updated my answer to include this – Sacchariferous

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

Wist

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

Accumulative