For on-premises deployments, ASP.NET Session State provides three built-in storage options (InProc, StateServer, and SqlServer) and a fourth "Custom" option. The first two built-in options (InProc & StateServer) have scalability problems, whereas, SqlServer option has both performance and scalability problems.
A much better strategy is to use the "Custom" option and plug-in NCache as your ASP.NET Session State Provider. NCache is an extremely fast and scalable Open Source distributed cache for .NET. It handles extreme transaction load by allowing you to add more cache servers at runtime and scale linearly. NCache also provides intelligent cache replication so you don't lose any ASP.NET Session State if a web server or a cache server goes down.
First of all, there is no programming required to use NCache as your ASP.NET Session State provider. You simply modify your web.config and specify NCache as your Session State Provider (SSP). See details on Configuring ASP.NET Session State Provider for NCache. Following are some of the benefits for using NCache as your ASP.NET Session State Provider:
High Availability: NCache has a self-healing peer to peer clustering architecture with no single point of failure. This provides 100% uptime for your ASP.NET Session State storage that is very important for business-critical applications.
Linear Scalability: NCache allows you to scale your cache cluster linearly by adding more cache servers to the cluster. This increases your transaction capacity and also your storage capacity. This means ASP.NET Session State storage never becomes a bottleneck for your application under heavy transaction loads.
Intelligent Session Replication: NCache provides rich caching topologies (Mirrored Cache, Replicated Cache, and Partition-Replica Cache) with intelligent session replication that does not compromise on performance and scalability. This ensures that you don't lose any session data when a web server or a cache server goes down.
Fast Compact Serialization: NCache provides a fast Compact Serialization that is faster than regular .NET serialization and requires no programming to use. Simply register your .NET classes with it and NCache generates serialization source code, compiles it in-memory at runtime when your application connects to the cache, and then uses this compiled code for all subsequent serializations.
NCache provides two ways for you to manage ASP.NET Session State for applications running in multiple regions (data centers) and still maintaining session consistency across them. They are:
WAN Replication of ASP.NET Session State: NCache provides a Bridge Topology to let you replicate your entire ASP.NET Session State store (the distributed cache) to other region (data center) across the WAN. This ensures that your sessions always exist in multiple regions (data centers). You can use this in active-passive (for disaster recovery) or active-active modes. In active-active, you can even load balance traffic between multiple regions (data centers). All of this is done through configuration changes.
Multi-Region ASP.NET Session State: If you don't want to replicate ASP.NET Session State across the WAN because of bandwidth consumption cost, you can choose to use this Multi-site ASP.NET Session State feature of NCache. In this, the ASP.NET Session State is not replicated across sites and instead is kept at the location of its creation. But, if you move any traffic from one region (data center) to another, the ASP.NET Session State moves with it.
This allows you to have two or more active regions (data centers), keep most of the traffic to its own datacenter but occasionally overflow to the other datacenter if you want. And, you can also bring down one datacenter without causing any interruptions for the users because their sessions will be accessible by other datacenters.
NCache ASP.NET Session State provider implements all the standard ASP.NET Session State Provider features. Additionally, it provides various advanced features to let you handle complex situations in your applications.
Share Sessions across App Domains: If you're using multiple app domains and for each app domain you have a separate web.config file, then specify the same value in
sessionAppId=>"NCacheApp1" and it results in the session sharing across those app domains. If you use a different Session App Id then sessions are not shared across app domains.
Error logging: You can enable error logging to a log file on your web server (in INSTALL_DIR\NCache\log-files\SessionStoreProvider folder) by specifying
enableLogs = "true" . You can also enable logging of errors to the Windows Event Log by specifying
writeExceptionsToEventLog = "true" .
Standard Session Locking: The standard ASP.NET session locking behavior is that if a session is locked, another request for it waits for 90 seconds (configurable) and at the end force-unlocks the session. You can specify this option as following:
enableSessionLocking = "true" sessionLockingRetry = "-1" emptySessionWhenLocked = "false"
Enhanced Session Locking: If you have a high traffic ASP.NET application where robots may be scraping data and using the same session id for hundreds or thousands of requests simultaneously, you cannot afford standard session locking option because waiting for 90 seconds could tie up all your available sockets. Instead, you want to return the request quickly to indicate a failure. You can specify this as following:
enableSessionLocking = "true" sessionLockingRetry = "5" emptySessionWhenLocked = "false"
This makes 5 retries at half-second intervals and then returns an empty session to signify a failure. Even throwing an exception here is costly. That is why an empty session is implemented. This behavior was originally implemented on a request from a high traffic airline website.