[转] Azure Redis Best Practices - ASP.Net Session State Provider & StackExchange.Redis

ASP.Net Session State Provider

Session State Best Practices

1. Enable session state only on required pages - This will avoid known session state provider performance problems.
   • You can disable session state by setting the web.config enableSessionState option to false.

     <system.web>
       <pages enableSessionState=false>
     

   • You can enable it on specific pages by setting the page directive's EnableSessionState option to true

     <%@ Page EnableSessionState=true %>
     

   • Mark pages using Session State as ReadOnly whenever possible - this helps avoid locking contention.

     <%@ Page EnableSessionState=ReadOnly %>
     

2. Avoid Session State (or at least use ReadOnly) on pages that have long load times - When a page with write-access to the session state takes a long time to load, it will hold the lock for that session until the load completes. This can prevent other requests for other pages for the same session from loading. Also, the session state module in ASP.NET will, in the background, continue to ask for the session lock for any additional requests for that same session until the lock is available or until the executionTime is exceeded for the lock. This can generate additional load on your session state store.
3. Make sure you understand the impact of session state locks. Read this article for an example of why this is important.
4. Select your httpRuntime/executionTime carefully - The executionTime you select is the duration that the session lock is held should the app crash without releasing the lock. Select a value that is as low as possible while still meeting your application's specific requirements.

Note: None of these recommendations are specific to Redis - they are good recommendations regardless of which SessionStateProvider you use. Also, some of these recommendations are based on this article, which has additional recommendations beyond those specifically called out here.

 

StackExchange.Redis

General Guidance

1. Set AbortConnect to false, then let the ConnectionMultiplexer reconnect automatically. See here for details

2. Reuse the ConnectionMultiplexer - do not create a new one for each request. The Lazy<ConnectionMultiplexer> pattern shown here is strongly recommended.

3. Configure your ThreadPool settings to avoid timeouts.

4. Be aware of the performance costs associated with different operations you are running. For instance, the "KEYS" command is an O(n) operation and should be avoided. The redis.io site has details around the time complexity for each operation that it supports.

5. Consider turning on "Server GC". "Workstation GC" is the default and can impact the latencies when garbage collection is in happening.

6. Most customers find that a single ConnectionMultiplexer is sufficient for their needs. However, if you have high throughput requirements, you may consider slowly increasing the number of connections to see if you get an improvement in throughput. Avoid setting it to an arbitrarily large number of connections as it may not give the desired benefit.

7. Configure supported TLS settings. If you are targeting .NET 4.7 or later, you should not have to do anything because StackExchange.Redis will automatically use the OS level settings when deciding which TLS versions to support (which is a good thing in most cases). If you are targeting an older version of .NET, then you should configure the client to use the highest TLS version that your client system supports (typically TLS 1.2). Once you move to a newer version of the .NET framework, then you should probably remove this configuration and let the OS settings take precedence. This can configured through the sslProtocols connection string entry (requires NuGet package version 1.2.3 or later), or through the ConfigurationOptions class as show here:

   var options = ConfigurationOptions.Parse(connectionString);

   options.SslProtocols = System.Security.Authentication.SslProtocols.Tls12;

   ConnectionMultiplexer.Connect(options);

Reconnecting with Lazy<T> pattern

We have seen a few rare cases where StackExchange.Redis fails to reconnect after a connection blip (for example, due to patching). Restarting the client or creating a new ConnectionMultiplexer will fix the issue. Here is some sample code that still uses the recommended Lazy<ConnectionMultiplexer>pattern while allowing apps to force a reconnection periodically. Make sure to update code calling into the ConnectionMultiplexer so that they handle any ObjectDisposedException errors that occur as a result of disposing the old one.

 

Sample Code:

using System;
using System.Threading;
using StackExchange.Redis;

static class Redis
{
    static long lastReconnectTicks = DateTimeOffset.MinValue.UtcTicks;
    static DateTimeOffset firstError = DateTimeOffset.MinValue;
    static DateTimeOffset previousError = DateTimeOffset.MinValue;

    static object reconnectLock = new object();

    // In general, let StackExchange.Redis handle most reconnects, 
    // so limit the frequency of how often this will actually reconnect.
    public static TimeSpan ReconnectMinFrequency = TimeSpan.FromSeconds(60);

    // if errors continue for longer than the below threshold, then the 
    // multiplexer seems to not be reconnecting, so re-create the multiplexer
    public static TimeSpan ReconnectErrorThreshold = TimeSpan.FromSeconds(30);

    static string connectionString = "TODO: CALL InitializeConnectionString() method with connection string";
    static Lazy<ConnectionMultiplexer> multiplexer = CreateMultiplexer();

    public static ConnectionMultiplexer Connection { get { return multiplexer.Value; } }

    public static void InitializeConnectionString(string cnxString)
    {
        if (string.IsNullOrWhiteSpace(cnxString))
            throw new ArgumentNullException(nameof(cnxString));

        connectionString = cnxString;
    }

    /// <summary>
    /// Force a new ConnectionMultiplexer to be created.  
    /// NOTES: 
    ///     1. Users of the ConnectionMultiplexer MUST handle ObjectDisposedExceptions, which can now happen as a result of calling ForceReconnect()
    ///     2. Don't call ForceReconnect for Timeouts, just for RedisConnectionExceptions or SocketExceptions
    ///     3. Call this method every time you see a connection exception, the code will wait to reconnect:
    ///         a. for at least the "ReconnectErrorThreshold" time of repeated errors before actually reconnecting
    ///         b. not reconnect more frequently than configured in "ReconnectMinFrequency"

    /// </summary>    
    public static void ForceReconnect()
    {
        var utcNow = DateTimeOffset.UtcNow;
        var previousTicks = Interlocked.Read(ref lastReconnectTicks);
        var previousReconnect = new DateTimeOffset(previousTicks, TimeSpan.Zero);
        var elapsedSinceLastReconnect = utcNow - previousReconnect;

        // If mulitple threads call ForceReconnect at the same time, we only want to honor one of them.
        if (elapsedSinceLastReconnect > ReconnectMinFrequency)
        {
            lock (reconnectLock)
            {
                utcNow = DateTimeOffset.UtcNow;
                elapsedSinceLastReconnect = utcNow - previousReconnect;

                if (firstError == DateTimeOffset.MinValue)
                {
                    // We haven't seen an error since last reconnect, so set initial values.
                    firstError = utcNow;
                    previousError = utcNow;
                    return;
                }

                if (elapsedSinceLastReconnect < ReconnectMinFrequency)
                    return; // Some other thread made it through the check and the lock, so nothing to do.

                var elapsedSinceFirstError = utcNow - firstError;
                var elapsedSinceMostRecentError = utcNow - previousError;

                var shouldReconnect =
                    elapsedSinceFirstError >= ReconnectErrorThreshold   // make sure we gave the multiplexer enough time to reconnect on its own if it can
                    && elapsedSinceMostRecentError <= ReconnectErrorThreshold; //make sure we aren't working on stale data (e.g. if there was a gap in errors, don't reconnect yet).

                // Update the previousError timestamp to be now (e.g. this reconnect request)
                previousError = utcNow;

                if (shouldReconnect)
                {
                    firstError = DateTimeOffset.MinValue;
                    previousError = DateTimeOffset.MinValue;

                    var oldMultiplexer = multiplexer;
                    CloseMultiplexer(oldMultiplexer);
                    multiplexer = CreateMultiplexer();
                    Interlocked.Exchange(ref lastReconnectTicks, utcNow.UtcTicks);
                }
            }
        }
    }

    private static Lazy<ConnectionMultiplexer> CreateMultiplexer()
    {
        return new Lazy<ConnectionMultiplexer>(() => ConnectionMultiplexer.Connect(connectionString));
    }

    private static void CloseMultiplexer(Lazy<ConnectionMultiplexer> oldMultiplexer)
    {
        if (oldMultiplexer != null)
        {
            try
            {
                oldMultiplexer.Value.Close();
            }
            catch (Exception)
            {
                // Example error condition: if accessing old.Value causes a connection attempt and that fails.
            }
        }
    }
}