Redis Best Practices

Redis-BestPractices-General.md

Some of the Redis best practices content has moved

This content from this markdown file has moved a new, happier home where it can serve more people. Please check it out : https://docs.microsoft.com/azure/azure-cache-for-redis/cache-best-practices.

NOTE: Client specific guidance listed below is still valid and should still be considered. I will update this document once all content has been moved.

Redis-BestPractices-Java-Jedis.md

Jedis Java Client

CONTENT MOVED: https://github.com/Azure/AzureCacheForRedis/blob/main/Redis-BestPractices-Java-Jedis.md

Sample Code

CONTENT MOVED: https://github.com/Azure/AzureCacheForRedis/blob/main/Redis-SampleCode-Java-JedisPool.java

Redis-BestPractices-Node-js.md

Node.js

CONTENT MOVED:

https://github.com/Azure/AzureCacheForRedis/blob/main/Redis-BestPractices-Node-js.md

Redis-BestPractices-PHP.md

PHP

CONTENT MOVED:

https://github.com/Azure/AzureCacheForRedis/blob/main/Redis-BestPractices-PHP.md

Redis-BestPractices-Session-State-Provider.md

ASP.Net Session State Provider

CONTENT MOVED: https://github.com/Azure/AzureCacheForRedis/blob/main/Redis-BestPractices-Session-State-Provider.md

Redis-BestPractices-StackExchange-Redis.md

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.

Redis-LazyReconnect.cs

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

// Source Code Usage License: https://gist.github.com/JonCole/34ca1d2698da7a1aa65ff781c37ecdea
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.
            }
        }
    }
}

Redis-SampleCode-Java-JedisPool.java

// CONTENT MOVED:
// https://github.com/Azure/AzureCacheForRedis/blob/main/Redis-SampleCode-Java-JedisPool.java

In the Redis-LazyReconnect.cs, at line number 57, inside the lock, we should re-read the value of previousReconnect.
elapsedSinceLastReconnect = utcNow - previousReconnect;

As this thread might have waited to acquire a lock and some other thread might have got it first and reconnected successfully, thus updating previousReconnect. And we are reading stale value in all other threads for this variable.