InProc vs. AppFabric session state with single web server

Question

I have an ASP.Net MVC application which makes significant use of session to save state (including large data collections). At present, it is hosted on a single web server. The session is set to the default of InProc.

An issue arises whereby the application freezes for some users when many users are on line. I guess that this is because InProc session does not scale too well, and that there is only so much memory available to the process. (What happens if memory demand exceeds the available memory - does it swap out to disk?)

I have a couple of solutions in mind that would help with scalability. (a) Sql server session state; (b) Configure session state to use AppFabric caching. The first option looks like a good solution, except that it will affect performance and require stored items to be serializable.

What about configuring session state to use AppFabric caching (aka Velocity) in an environment where the single web server is also used as the cache host? How does this differ from InProc in this single-server environment? Will this provide more scalability and available memory than InProc, or will it essentially amount to the same constraints?

Answer 1

You would be better off implementing AppFabric Cache for your scenario. As your system grows, you can increase the number of cache servers with each new web node - something you cannot easily do with SQL Server without additional cost. SQL Server licensing also costs much more than AppFabric - which is bundled with a Windows Server license.

The only benefit SQL Server will provide is recoverability, but for what you need, it's probably overkill.

See related SO post discussing AppFabric Cache vs. SQL Server for session.

---

As for AppFabric Cache vs. InProc...

You could put your AppFabric Cache on another server if you are running into memory limitations. You can't do this with InProc.

Here are some other miscellaneous benefits of the AppFabric Cache:

1. Supports Local Cache to speedup retrieval costs involved in serializing/deserializing.
2. Provides finer grained controls with respect to cache eviction and expiration policies.
3. Supports compression of session contents to reduce network bandwidth.
4. Blob mode versus single item retrieval to improve data retrieval for large objects.
5. Same session state store can be used across multiple applications (via sharedId).

Answer 2

The most important thing is that the session will survive an app-pool recycle and even a redeploy of the application.

Also AppFabric can serialize IXmlSerializable objects as well as [Serializable]. If you try to use the out-of-proc ASP.NET session service you ironically cannot serialize IXmlSerializable objects such as XElement. You can also do completely customized serialization if you want. With AppFabric your app is much more 'azure' ready if you ever move that way.

Then of course you can use it for caching other data if you have a need for that.