Is Memcached interchangeable with ASP.NET State Server?

Question

Hi,

I use ASP.NET and WCF services in a load balanced web server environment, using Memcached in the service layer.

I also wanted to replace the use of ASP.NET State Server (for Session State) with Memcached. Now I am afraid it is not a good thing, because from what i understand, Memcached is a cache server rather than a state server, is that true?

If I understand correctly, Memcached is not distributing data to other nodes in the Memcached farm. Instead, a special hashing algorithm is used to determine which one of the nodes in the farm contains the data of a requested key, whereas ASP.NET State Server distributes data ASAP when it has been added, to prevent a Single Point of Failure.

In other words, Memcached should be used only for performance reasons, the data stored in it should always be re-creatable, in case the item has been removed to make room for new objects, or in case the single machine actually storing the data went down.

So can I not rely on Memcached only for storing session state data? If i can't, then i don't understand how Memcached is often compared to and seen as an alternative to using ScaleOut StateServer and ASP.NET State Server, since these are really state servers, which is another thing, right?

I am now a bit unsure as to what is the best approach for high performance distributed session state in a web server farm.

Thanks

Answer 1

Memcached doesn't support data mirroring at present, it only provides the ability to split your entries across multiples servers to try to prevent one from getting swamped. This works by either hashing your key with the address of the server, or by using the consistent hashing algorithm (libketama).

In general though, Memcached should not be viewed as a persistent storage layer, and in almost all cases, the data in the cache should be the same as in the database. If you are making a change to a user's session data and want to cache it, update it in Memcached, then update it in the database immediately afterward. If you want to be really careful, you could implement a simple journalling system to make sure this data stays consistent in the case of a system failure.

Memcached is definitely being used for caching sessions though, the creator says as much in a Jinux Journal article. It is really only meant for optimizing read operations, at the end of the day, any data you care about should be stored in the database.

Answer 2

In an ideal situation, the session data is only a single value, the internal numerical representation of the user id. It means that the user has passed the login page successfully with providing the correct password.

But what about others like, take stackoverflow for example, the dynamic data on the page depending on the user: the nickname of the user, the reputation number, the badges earned, the permssion to leave a comment. They are often the result of multiple JOINs across multiple database tables.

If you don't put memcached in use, these queries almost always read data from disk, which is a very slow, not very scalable operation. The cache inside the database? What do you think the hit ratio would be considering the database does things other than managing session data? Why do you have to read from disk while you can from memory?

Of course, any writes to the relevant user information should invalidate the corresponding session in memcached.

Answer 3

http://www.codeplex.com/memcachedproviders has a session state provider for asp.net that stores values in memcached. It provides the ability to backup the session data in ' SQL Server. As yogman said the session data is stored as one value. If an eviction happends, whole session for that user is lost and user will be directed to the login screen. Memcached doesn't evict any data before expiration unless it is running out of space to hold new data.