ASP.NET Session State Configuration in Web Farms
ASP.NET Session State provides the following storage options:
- InProc: sessions kept within worker process
- StateServer: sessions kept in a stand-alone process
- SqlServer: sessions kept in the database as BLOBs
- Custom: plug-in third party session storage like NCache
InProc cannot handle web gardens at all and handles web farms only by using sticky session feature in load balancer that prevents scalability. StateServer has performance and scalability issues. And, with both options you lose session data in case a web server goes down. SqlServer has performance and scalability issues because SQL Server was designed for structured data and not BLOBs.
A much better strategy is to use the "custom" option and plug-in a distributed cache like NCache as your ASP.NET Session State storage. NCache is extremely fast and scales linearly by letting you add more cache server to handle greater transaction loads and greater storage capacity. NCache also provides intelligent replication of ASP.NET Session State so you don't lose any sessions if a web server or a cache server goes down.
Configure ASP.NET Session State with NCache
The best thing about using NCache for ASP.NET Session State storage is that there is no programming required on your part. You simply modify your
web.config and specify NCache as your Session State Provider (SSP) as following:
Some of the NCache specific features of ASP.NET Session State Provider (SSP) are explained below:
Share Sessions across App Domains (or not): If multiple app domain
web.config files specify the same value in
sessionAppId="NCacheApp1" it results in session sharing across those app domains. If they use different values here then sessions are not shared.
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
- 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:
- Custom Session Locking: If you have a high traffic website 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:
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.
Benefits of using ASP.NET Session State with NCache
By plugging in NCache ASP.NET Session State Provider (SSP) through web.config changes, you gain an enterprise level distributed cache for your ASP.NET application with the following:
- 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 servers to the cluster. This increases your transaction and your storage capacity linearly. This means ASP.NET Session State storage never becomes a bottleneck for your application under heavy loads.
- Intelligent Session Replication: NCache provides rich caching topologies (Mirrored, Replicated, and Partition-Replica Cache) with intelligent session replication without compromising on performance and scalability. This ensures that you don't lose any session data when a web server or a cache server goes down.
- Faster Dynamic Compact Serialization: ASP.NET serializes the session object before persisting it. And, it uses regular .NET serialization that in turn uses .NET Reflection at runtime and is therefore quite slow. NCache provides almost 10 times faster Dynamic Compact Serialization that requires no programming. You register your .NET classes with NCache and NCache generates serialization source code and compiles it in-memory at runtime when your application connects to the cache and then uses this compiled code for all subsequent serializations.
Support for Storing ASP.NET Sessions in Multiple Data Centers
NCache provides two ways for you to handle your ASP.NET applications running in multiple 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 datacenters across the WAN. This ensures that your sessions always exist in multiple datacenters. 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 datacenters. All of this is done through configuration changes.
- Multi-site 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, then it is accessible to your ASP.NET application that is running in other datacenters.