ASP.NET Core Session Provider for NCache in Web Farms

ASP.NET Core has been completely re-architected and therefore has a different session management system than the older ASP.NET.

Although ASP.NET Core provides an in-memory session provider that stores sessions on the webserver itself, ASP.NET Core session storage in web farms is challenging.

One approach is to use sticky-sessions in web farms that route all the user requests to the same web server through the Application Request Routing module. But, sticky sessions can affect scalability and lead to improper load distribution. A relatively better approach is to use SQL Server for session storage. However, when it comes to scalable ASP.NET core applications, the SQL databases become a performance bottleneck. This is because SQL Server (like all relational databases) is not good at storing BLOBs and sessions are saved in the database as BLOBs.

A viable option is to use a distributed cache for storing ASP.NET Core sessions in a web farm. And, the most appropriate Distributed Cache for this purpose is NCache that provides a powerful and feature-rich ASP.NET Core Session Service that you can use.

NCache is an extremely fast and scalable distributed cache for .NET/.NET Core. It handles extreme transaction load by allowing you to add more cache servers at runtime and scale linearly. Meanwhile, NCache high availability and dynamic cache clustering ensure that you don't lose any ASP.NET Core Session data if a web server or a cache server goes down.

ASP.NET Core Session - NCache

Configuring ASP.NET Core Session Provider for NCache

Unlike ASP.NET where you only modify web.config, ASP.NET requires you to modify the "ConfigureServices()" method in the Startup class. The following code shows that how you can do it for NCache. For more details, see NCache ASP.NET Core Session Provider Configuration docs and follow the steps.

public void ConfigureServices(IServiceCollection services)
{
    // Add framework services
    services.AddMvc();

    // Add NCache Session service to IServiceCollection with various configuration 
    // options

    services.AddNCacheSession(configuration =>
    {
        configuration.CacheName = "mySessionCache";
        configuration.EnableLogs = true;
        configuration.SessionAppId = "NCacheSessionApp";
        configuration.SessionOptions.IdleTimeout = 5;
        configuration.SessionOptions.CookieName = "AspNetCore.Session";
    });
}

Benefits of ASP.NET Core Session Provider for NCache

First of all, there is very little programming required to use NCache as your ASP.NET Core Session Provider; the code change is in the ConfigureServices(IServiceCollection services) method in the Startup class. See details on Configure ASP.NET Core Session Provider for NCache. Following are some of the benefits for using NCache as your ASP.NET Core Session State Provider:

  1. High Availability: Your ASP.NET Core application most requires high availability from anything it depends on in production. And, NCache provides you this through a self-healing peer to peer clustering architecture that has no single point of failure. NCache also replicates ASP.NET Core Sessions so there is no data loss in case a server goes down.

  2. Linear Scalability: Your ASP.NET Core application most likely needs to scale to handle high transaction loads. And, if your ASP.NET Core Session store does not scale then your application won't either. Fortunately, NCache provides linear scalability and never becomes a bottleneck for your ASP.NET Core application.

  3. Intelligent Session Replication: Although session replication provides high availability, but it comes with a performance cost. NCache minimizes this cost through its rich caching topologies (Mirrored Cache, Replicated Cache, and Partition-Replica Cache). NCache replicates data without sacrificing performance in any noticeable way and yet achieves data reliability.

  4. Fast Dynamic Compact Serialization: Regular .NET serialization is often slow and bulky for larger objects. To handle this bottleneck, NCache has implemented a Dynamic Compact Serialization that is much faster. You just have to register your classes and NCache does the rest. No programming is needed. Upon connection time, NCache generates serialization source code, compiles it in-memory, and then uses it for serialization.

Support for Multiple Regions (Data Centers)

NCache allows you to manage ASP.NET Core Sessions for applications running in multiple regions (data centers). Here they are:

  1. WAN Replication of ASP.NET Core Sessions: NCache provides a Multi-Datacenter WAN Replications feature that also lets you replicate all the ASP.NET Core sessions across the WAN to another region (datacenter). This is done through a Bridge Topology feature of NCache. This ensures that your ASP.NET Core sessions are never lost even if a region (data center) goes down.

  2. 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 NCache Multi-site ASP.NET Session State feature. 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. For further details, you can read our product page for Multi-Region ASP.NET Session State Provider for NCache.

Advanced Features in NCache ASP.NET Core Session Provider

ASP.NET Core Session Provider for NCache implements all the standard ASP.NET Core Session Provider features. Additionally, it implements various advanced features to let you handle complex situations in your applications in the ConfigureServices(IServiceCollection services) method.

  1. Standard Session Locking: The standard ASP.NET Core session locking behavior is that the session is never locked. As a result, you may corrupt the session if you try to update it simultaneously. So, NCache has implemented a session locking feature similar to the older ASP.NET Session State where 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 locking option as following properties in the "configuration":

    services.AddNCacheSession(configuration =>
    {
    configuration.RequestTimeout = 90;
    configuration.EnableSessionLocking = true;
    configuration.SessionLockingRetry = -1;
    configuration.EmptySessionWhenLocked = false;
    ...
    });
  2. Enhanced Session Locking: For a high traffic ASP.NET Core application, you may have robots scraping data and using the same session id for hundreds or thousands of requests simultaneously. In this case, 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:

    services.AddNCacheSession(configuration =>
    {
    configuration.EnableSessionLocking = true;
    configuration.SessionLockingRetry = 5;
    configuration.EmptySessionWhenLocked = true;
    ...
    });

    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.

  3. 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 the "EnableLogs" and "WriteExceptionsToEventLog" configuration properties as following:

    services.AddNCacheSession(configuration =>
    {
    configuration.EnableLogs = true;
    configuration.WriteExceptionsToEventLog = false;
    ...
    });
    

What to Do Next

Signup for monthly email newsletter to get latest updates.

Contact Us

PHONE

+1 (214) 764-6933 (US)

+44 20 7993 8327 (UK)

© Copyright Alachisoft 2002 - . All rights reserved.