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.
Key Takeaways
Problem: InProc and StateServer modes in ASP.NET are single-point-of-failure risks for Web Farms.
Limitation: SQL Server offers reliability but introduces performance bottlenecks due to relational data storage of blobs.
Solution: Distributed caching (like NCache) provides the best balance of speed, scalability, and reliability for Session State.
Implementation: Requires minimal code changes, primarily updating the web.config file.
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.
| Storage Option | Reliability | Performance | Scalability | Suitability for Web Farms |
| InProc | Low (Data lost on restart) | High (Local memory) | None (Single server only) | Not Suitable (Dev/Test only) |
| StateServer | Medium (Separate process) | Medium (Serialization overhead) | Low (Single point of failure) | Low (Risk of total outage) |
| SQL Server | High (Persisted to disk) | Low (Disk I/O & BLOBs) | Medium (Database bottleneck) | Medium (High cost & latency) |
| NCache (Custom) | High (Replicated in-memory) | High (Sub-millisecond access) | High (Linear scalability) | Best Practice (100% Uptime) |
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 |
<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> |
Common Configuration Pitfalls
- Mismatched Machine Keys: Ensure all servers in the web farm have the exact same
<machineKey>in web.config for encryption/decryption consistency. - Missing Assemblies: Verify that NCache.Web.dll is properly referenced or available in the GAC on all web servers.
- Firewall Rules: Ensure port 7800 (default NCache TCP port) is open between Web Servers and Cache Servers.
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.
Frequently Asked Questions (FAQ)
Q: Why shouldn’t I use InProc for a Web Farm?
A: InProc stores sessions in the memory of a specific web server. In a web farm, if a user request is routed to a different server, the session data will be missing.
Q: Does NCache require code changes for ASP.NET Session State?
A: No, NCache requires zero code changes. You only need to update the sessionState tag in your web.config file.
Q: How does Distributed Caching improve Session State performance?
A: It stores session data in memory across multiple servers, eliminating the disk I/O bottlenecks associated with SQL Server storage.
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.