ASP.NET is renowned for its role in developing high-traffic web applications, that are often deployed across multiple geographical locations. Such deployments serve dual purposes: ensuring the application is prepared for disaster recovery scenarios with an active-passive site setup, where the passive site takes over if the active site fails. And, optimizing regional traffic by placing these ASP.NET applications closer to end-users, for instance, in New York, London, and Tokyo, where multiple sites can concurrently handle local traffic.
Optimizing ASP.NET Session State with NCache
ASP.NET stores user-specific information within its Session State object on the web server, which is created when a user first accesses the application and persists as long as the user remains active. By default, ASP.NET expires such sessions after 20 minutes of user inactivity.
The ASP.NET Session State object can be stored in various ways; in-memory on the web server (InProc), on a separate state server (StateServer), in a SQL Server database, or in a third-party store using SSP (Session State Provider) architecture. Opting for a third-party store like NCache, an in-memory distributed cache, offers better performance, greater scalability, and enhanced reliability due to session replication.
Here’s an example of configuring NCache as the ASP.NET Session State storage in the web.config file:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 |
<sessionState cookieless ="false" regenerateExpiredSessionId="true" mode="Custom" customProvider="NCacheSessionProvider" timeout="20" sessionIDManagerType="Alachisoft.NCache.Web.SessionStateManagement.CustomSessionIdManager, Alachisoft.NCache.SessionStateManagement"> <providers> <add name ="NCacheSessionProvider"> type="Alachisoft.NCache.Web.SessionState.NSessionStoreProvider" sessionAppId="demoApp" cacheName="demoClusteredCache" writeExceptionsToEventLog="false" asyncSession="false" enableLogs="false"/> </providers> </sessionState> |
Active-Passive Multi-Site Deployment for ASP.NET Session State Storage
However, if your application runs in a multi-site deployment, then you must address ASP.NET Session State storage. As, if you have deployed your ASP.NET application in an active-passive multi-site configuration, then all your ASP.NET Session States are being created and stored in the active site. The passive site does not have any session data. So, if the active site goes down and all the traffic redirects to the passive site, all users will suddenly lose their sessions and have to start over. You can avoid this by using the NCache Bridge Topology.
Once you create a Bridge between the active and passive sites, the active site starts sending all additions, updates, and removals of ASP.NET Session State objects to the Bridge. The Bridge then replicates these changes asynchronously across the WAN to the passive site. The Bridge architecture does not block the active site operations, so you do not see any performance degradation. Unfortunately, as the Bridge replicates asynchronously, there may be some sessions in the “replication queue” that won’t make it to the passive site if the active site shuts down abruptly. But this is usually an insignificant number. Explore the advantages of the NCache Bridge Topology further here.
Active-Active Multi-Site Deployment for ASP.NET Session State Storage
If your ASP.NET application is deployed on two or more active sites simultaneously, then you should avoid replicating ASP.NET Session State everywhere to save on bandwidth costs. However, you will probably want to route some traffic to other sites in overflow situations.
Alternatively, you may need to bring one of the sites down for maintenance without interrupting the users. In this case, you can use the multi-site ASP.NET Session State Storage feature in NCache. This feature allows you to manage these scenarios by configuring the web.config to generate session IDs prefixed with the location of the “primary” site for the session. Therefore, even if the session request is routed to another site, that site can locate and access this session correctly.
The sessions do not move from their primary location regardless of user routing requests to other sites. However, secondary sites can access these sessions from their “primary” site. Each site specifies its “primary” and all others as “secondary” sites. Below are the steps you need to take to achieve this goal:
- Add entry in the web.config after generating an ASP.NET session-id in the same manner on all servers and sites. You can use the genmackeys utility available with NCache installation to generate the keys.
1<machineKey validationKey ="A01D6E0D1A5D2A22E0854CA612FE5C5EC4AECF24" decryptionKey ="ACD8EBF87C4C8937" validation ="SHA1"/> - To enable location affinity of a session-id, add the configuration mentioned below:
12345678910<configSections><section name="ncache" type="Alachisoft.NCache.Web.SessionStateManagement.NCacheSection,Alachisoft.NCache.SessionStateManagement, Version=x.x.x.x, Culture=neutral, PublicKeyToken=CFF5926ED6A53769"/></configSections><ncache><sessionLocation><primaryCache id="London_Cache" sid-prefix="LDNC"/><secondaryCache id="NewYork_Cache" sid-prefix="NYKC"/><secondaryCache id="Tokyo_Cache" sid-prefix="TKYC"/></sessionLocation></ncache> - Specify custom session-id manager using the sessionIDManagerType attribute of the sessionState element in web.config.
12345678910111213141516<sessionState cookieless ="false"regenerateExpiredSessionId="true"mode="Custom"customProvider="NCacheSessionProvider"timeout="20" sessionIDManagerType="Alachisoft.NCache.Web.SessionStateManagement.CustomSessionIdManager, Alachisoft.NCache.SessionStateManagement"><providers><add name ="NCacheSessionProvider"type="Alachisoft.NCache.Web.SessionState.NSessionStoreProvider"sessionAppId="demoApp"cacheName="demoClusteredCache"writeExceptionsToEventLog="false"asyncSession="false"enableLogs="false"/></providers></sessionState>
Please note that in the above example, the section in each site will be different, meaning each site will have its own “primary” and will consider all other sites as “secondary”.
ASP.NET generates a sid (session id) in a specific format so that its sid prefix can be part of the session-id. This id helps ASP.NET learn the origin of the ASP.NET Session State so the cache for that site is accessible. With this configuration, if you route any requests from one site to another for overflow, the other site fetches the ASP.NET Session State from its original “primary” site because this is part of the session-id as a location prefix. It minimizes your WAN bandwidth consumption, and you only pay for overflow traffic.
The other situation is when you want to bring a site down. You can redirect all of the site’s traffic to other sites without shutting down the cache servers of this site; you can shut down the web servers. Then wait for all existing ASP.NET Session State objects to expire after their users have stopped using the application. Once traffic redirects, just shut down the cache servers. With this, your users will not feel any downtime.
Conclusion
NCache is the ideal solution for managing ASP.NET Session State in multi-site deployments. Whether you’re ensuring disaster recovery with active-passive setups or optimizing regional traffic with active-active sites, NCache’s in-memory distributed caching and session replication provide the performance, scalability, and reliability needed. Learn more about how you can achieve this goal by downloading a fully working 30-day trial of NCache today!
