ASP.NET has come to age with numerous high-traffic mission-critical ASP.NET applications. That means you cannot afford unscheduled downtime for the entire website or any particular servers with users getting bumped out. 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.
ASP.NET Session State Storage Options
Microsoft offers four storage options for this.
- InProc: Sessions kept inside the 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 can’t replicate ASP.NET Session State to more than one server and cause data loss if any web server goes down. If you have a single StateServer for the entire website and it goes down, you’re out of luck because your website will go down. The third storage option for Session State, SqlServer, does provide server redundancy and data replication because you can build a database cluster (mirrored or load-balanced).
But, it’s expensive to set up SQL Server clusters, especially when cheaper and more viable alternatives are available. Additionally, SQL Server (like all relational databases) stores structured relational data, not BLOBs, even though it stores the ASP.NET Session State as such. Thus, these sessions are slow to respond, and the database quickly becomes a scalability bottleneck.
Why Custom Storage is the best option for ASP.NET Session State?
A considerably better alternative is to use the Custom storage option of ASP.NET Session State and use an in-memory distributed cache (NCache) as your 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 scale the cache cluster as your web farm grows by adding more cache servers to the cluster so there is never a bottleneck.
Using Distributed Caching for ASP.NET Session State Storage
Further, you can use NCache for ASP.NET Session State storage with minimal code changes. All you need to do is 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 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 |
<configuration> ... <sessionState cookieless="false" regenerateExpiredSessionId="true" mode="Custom" customProvider="NCacheSessionProvider" timeout="20"> <providers> <add name="NCacheSessionProvider" type="Alachisoft.NCache.Web.SessionState.NSessionStoreProvider" cacheName="demoCache" sessionAppId="demoApp" useInProc="false" enableLogs="false" exceptionsEnabled="true" writeExceptionsToEventLog="false" AsyncSession="false" useJsonSerialization="false" enableLogs="false" enableSessionLocking="true" sessionLockingRetry="-1" emptySessionWhenLocked="false" /> </providers> </sessionState> ... </configuration> |
Conclusion
Undoubtedly, the best course of action you can take is to employ ASP.NET Session State Custom storage option and use NCache an in-memory distributed cache. Moreover, opting for NCache will give you access to NCache’s vast feature set, taking your application performance to the next level.
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.