There are various known, proven and "old" ways to store ASP.NET (and ASP.NET MVC) session state data: from most simple in-process mode (when data stored directly in the memory on the Web server) to Microsoft SQL Server mode (see more details at
http://msdn.microsoft.com/en-us/library/ms178586.ASPX). Millions of sites use one of them and happy with solutions provided by Microsoft (see how it is easy to configure MS SQL Server over few minutes, for example, at
http://support.microsoft.com/kb/317604/en-us.)
At the same time, some companies may experience different issues with "standard" modes, including:
- Limitations on use for Web Farms. For example, In-proccess mode does not work with multiple front-end servers which want to share sessions.
- Storage size, scaling issues and no failover / persistency in State Server mode, i.e. Windows Service which allows to store sessions will not persist sessions data on service / server restart and can't easy be scaled to multiple session storage servers
- SQL Server is not free if you want to use cluster (Express edition does not support such extended features) and is not that efficient. If your session size is relatively big or you have thousands concurrent sessions performance issues may become visible because SQL Server is not "in memory" database. Well, at least before just released SQL Server 2014 version it does not have such capabilities and I have no data yet how it works with memory optimized tables. In any case, usage of MS SQL Server feels like overkill for simple key-value session data!
So from all ASP.NET Session modes, of course the most exciting for us is "Custom" mode which allows to use custom provider and store session data in some non-standard storages. The focus of this post is to review how to use Couchbase provider to get better scalability, performance and failover protection of your ASP.NET web application sessions storage.
Couchbase is open-source NoSQL document database with the community edition free for production usage (sure commercial editions are also available with additional support and features).
Couchbase supports two storage types: Memcached (that store all data in memory and does not persist data to disk) or Couchbase (that do persists data to disks). If your primary concerns are performance and you care less about unlikely even when Couchbase node goes down (say hardware failure), you can use the Memcached storage. If you use SSD disks and want complete failover protection with persistence, you better select Couchbase storage instead (writes to SSD disks will be async so performance still will be high).
Now, to use Couchbase sessions provider, I recommend to install it using NuGet, e.g.:
Install-Package CouchbaseAspNetExtended
<section name="couchbaseSession" type="Couchbase.Configuration.CouchbaseClientSection, Couchbase"/>
<couchbaseSession>
<servers bucket="sessionState" bucketPassword=""><add url="
</servers>
</couchbaseSession>
<sessionState customProvider="Couchbase" mode="Custom">
<providers>
<add name="Couchbase" type="Couchbase.AspNet.SessionState.CouchbaseSessionStateProvider, Couchbase.AspNet" section="couchbaseSession" />
</providers>
</sessionState>
Note1: there is a limitation on 1Mb (Memcached mode) or 20Mb (Couchbase mode) for user session size. If for whatever reason your session data is bigger than that (not that recommended practice, always better to keep session small), you can enable provider compression (see more details on provider documentation page).
Note2: Session handler also supports the ability to disable exclusive session access for ASP.NET sessions if desired (may significantly improve performance of your Web application). You can set the value using the "exclusiveAccess" attribute of the provider entry, e.g.:
<providers>
<add name="Couchbase" type="Couchbase.AspNet.SessionState.CouchbaseSessionStateProvider, Couchbase.AspNet" exclusiveAccess="false" />
</providers>
After Couchbase Server installed and Couchbase provider configured you can start use build-in management and monitoring UI to see realtime Sessions data statistics (qty of requests, storage size etc), e.g.:
