Redis Best Practices

Redis-BestPractices.md

Best Practices for Azure Redis

Below are a set of best practices that I recommend for most customers. This information is based on my experience helping hundreds of Azure Redis customers investigate various issues.

##Configuration and Concepts

1. Use Standard or Premium Tier for Production systems. The Basic Tier is a single node system with no data replication and no SLA. Also, use at least a C1 cache. C0 caches are really meant for simple dev/test scenarios since they have a shared CPU core, very little memory, are prone to "noisy neighbor", etc.
2. Remember that Redis is an In-Memory data store. Read this article so that you are aware of scenarios where data loss can occur.
3. Develop your system such that it can handle connection blips due to patching and failover.
4. Configure your maxmemory-reserved setting to improve system responsiveness under memory pressure conditions, especially for write-heavy workloads or if you are storing larger values (100KB or more) in Redis.

##StackExchange.Redis

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. Redis works best with smaller values, so consider chopping up bigger data into multiple keys. In this Redis discussion, 100kb is considered "large". Read this article for an example problem that can be caused by large values.
4. Configure your ThreadPool settings to avoid timeouts.
5. Use at least the default connectTimeout of 5 seconds. This would give StackExchange.Redis sufficient time to re-establish the connection, in case of a network blip.
6. 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.

##Performance Testing

1. Start by using redis-benchmark.exe to get a feel for possible throughput/latency before writing your own perf tests. Redis-benchmark documentation can be found here http://redis.io/topics/benchmarks. Note that redis-benchmark does not support SSL, so you will have to enable the Non-SSL port through the Azure Portal before you run the test. A windows compatible version of redis-benchmark.exe can be found here
2. The client VM used for testing should be in the same region as your Redis cache instance.
3. We recommend using Dv2 VM Series for your client as they have better hardware and will give the best results.
4. Make sure your client VM you choose has at least as much computing and bandwidth capability as the cache you are testing.
5. Enable VRSS on the client machine if you are on Windows. See here for details. Example powershell script:

PowerShell -ExecutionPolicy Unrestricted Enable-NetAdapterRSS -Name (Get-NetAdapter).Name

6. Premium tier Redis instances will have better network latency and throughput because they are running on better hardware foro both CPU and Network.

Note: Our observed performance results are published here for your reference.

###Redis-Benchmark Examples Setup the cache:

redis-benchmark.exe -h yourcache.redis.cache.windows.net -a yourAccesskey -t SET -n 10 -d 1024

Test Latency for GET requests using a 1k payload:

redis-benchmark.exe -h yourcache.redis.cache.windows.net -a yourAccesskey -t GET -d 1024 -P 50 -c 4

Test throughput you are able to get using Pipelined GET requests with 1k payload.

redis-benchmark.exe -h yourcache.redis.cache.windows.net -a yourAccesskey -t GET -n 1000000 -d 1024 -P 50 -c 50