There is absolutely no doubt about it. ASP.NET has come to age and a good majority of ASP.NET applications now are high traffic and mission-critical. That means you cannot afford unscheduled downtime of either the entire website or some of the servers where many users are getting bumped out. This is because these downtimes cost you dearly in lost revenue and a bad reputation that is hard to fix.
ASP.NET Session State storage if not handled correctly can cause unscheduled downtimes. Microsoft offers four storage options for ASP.NET Session State:
- InProc: Sessions kept inside worker process
- StateServer: Session kept in a separate process
- SqlServer: Session kept in SQL Server
- Custom: Session kept in a third-party custom store
Both InProc and StateServer don’t have the capability to replicate ASP.NET Session State to more than one server and therefore cause data loss if any web server goes down. In fact, if you have a single StateServer for the entire website and it goes down, you’re totally hosed because your entire website will go down.
SqlServer is the third storage option for ASP.NET Session State and it does provide server redundancy and data replication because you can build a database cluster, either mirrored or load-balanced cluster.
But, it’s expensive to setup SQL Server clusters and there are cheaper and more viable alternatives available. Additionally, SQL Server (like all relational databases) was designed to store structured relational data and not BLOBs; whereas, ASP.NET Session State is stored in SQL Server as BLOBs. So, not only are the sessions slow to access but the database quickly becomes a bottleneck as you try to scale your application.
A considerably better alternative to all of this is to use the Custom storage option of ASP.NET Session State and use an in-memory distributed cache (NCache) as your ASP.NET Session State storage. NCache replicates sessions across multiple servers so if any one server goes down, there’s no loss of session data. NCache is also much faster to access than SQL Server because it is in-memory. Finally, NCache allows you to easily scale the cache cluster as your web farm size grows. Simply add more cache servers to the cluster so there is never a bottleneck.
And, best of all, there is no programming needed to use NCache for ASP.NET Session State storage. Simply modify your web.config to specify the following:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 |
<assemblies> <add assembly="Alachisoft.NCache.SessionStoreProvider, Version=4.4.0.0, Culture=neutral, PublicKeyToken=CFF5926ED6A53769"/> </assemblies> <sessionState cookieless="false" regenerateExpiredSessionId="true" mode="Custom" customProvider="NCacheSessionProvider" timeout="20"> <providers> <add name="NCacheSessionProvider" type="Alachisoft.NCache.Web.SessionState.NSessionStoreProvider" sessionAppId="NCacheTest" enableLogs="false" cacheName="myReplicatedCache"/> </providers> </sessionState> |
Well, if you have an ASP.NET application running in a web farm, take a look at NCache and see how it will improve your ASP.NET Session State storage. Here are some useful links for NCache:
You can start off with minimum of two dedicated servers in a cache cluster for high availability and reliability and then it is recommended to maintain a 4:1 ratio between your Web/App servers and cache servers to get an optimum performance and scalability for your applications.