×


Best practices for Azure Cache for Redis

The Azure Redis Cache is a high-performance caching service that provides in-memory data store for faster retrieval of data. It is based on the open-source implementation Redis cache. This ensures low latency and high throughput by reducing the need to perform slow I/O operations.

Redis has a critical low-latency and high-throughput data storage solution to modern applications. Azure Cache for Redis offers Redis as a managed service.

Here at Ibmi Media, as part of our Server Management Services, we regularly help our Customers to perform Azure Cache for Redis related tasks.


More about Azure Cache for Redis?

Azure Cache for Redis provides secure and dedicated Redis server instances and full Redis API compatibility. 

The service is operated by Microsoft, hosted on Azure, and accessible to any application within or outside of Azure.

Further, it can also be used as a distributed data or content cache, a session store, a message broker, and more.

And can be deployed as a standalone or alongside other Azure database services, such as Azure SQL or Cosmos DB.


Service tiers

Azure Cache for Redis is available in the following tiers:

1. Basic: A single node cache. This tier supports multiple memory sizes (250 MB – 53 GB)and is ideal for development/test and non-critical workloads. 

The Basic tier has no service-level agreement (SLA).

2. Standard: A replicated cache in a two-node, primary/replica, configuration managed by Azure with a high-availability SLA.

3. Premium: The Premium tier is the Enterprise-ready tier. Premium tier Caches support more features and have higher throughput with lower latencies. Caches in the Premium tier are deployed on more powerful hardware providing better performance compared to the Basic or Standard Tier.


Best practices for Azure Cache for Redis

By following the best practices, we can maximize the performance and cost-effective use of Azure Cache for Redis instance.

Configuration and concepts

1. Firstly, use the Standard or Premium tier for production systems.

2. Redis is an in-memory data store.

3. Develop the system in a way to handle connection blips because of patching and failover.

4. Configure the max memory-reserved setting to improve system responsiveness under memory pressure conditions.

5. Redis works best with smaller values, so consider chopping up bigger data into multiple keys.

6. Locate the cache instance and the application in the same region. Connecting to a cache in a different region can significantly increase latency and reduce reliability.

7. Reuse connections. Creating new connections is expensive and increases latency, so reuse connections as much as possible.

8. Configure the client library to use a connect timeout of at least 15 seconds, giving the system time to connect even under higher CPU conditions.

9. Avoid expensive operations – Some Redis operations, like the KEYS command, are very expensive and should be avoided.

10. Use TLS encryption – Azure Cache for Redis requires TLS encrypted communications by default. TLS versions 1.0, 1.1, and 1.2 are currently supported.

11. Idle Timeout – Azure Redis currently has a 10-minute idle timeout for connections, so this should be set to less than 10 minutes.


Memory management

1. Choose an eviction policy that works for the application.

2. Set an expiration value on keys.


Performance testing

1. Start by using redis-benchmark.exe to get a feel for possible throughput/latency before writing our own perf tests. Note that redis-benchmark does not support TLS, so we will have to enable the Non-TLS port through the Portal before we run the test.

2. The client VM used for testing should be in the same region as our Redis cache instance.

3. Using  Dv2 VM Series for our client as they have better hardware and will give the best results.

4. Make sure the client VM we use has at least as much bandwidth as the cache being tested.

5. Enable VRSS on the client machine on Windows. Example PowerShell script:

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

7. Consider using Premium tier Redis instances. These cache sizes will have better network latency and throughput because they are running on better hardware for both CPU and Network.


Redis-Benchmark examples

Pre-test setup: Prepare the cache instance with data required for the latency and throughput testing commands listed below:

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


To test latency: Test GET requests using a 1k payload:

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


To test throughput: Pipelined GET requests with 1k payload.

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


[Need assistance to fix Redis Cache related errors? We are happy to help you. ]


Conclusion

This article will guide you on some of the Best practices for Azure Cache for Redis. By following these best practices, you can help maximize the performance and cost-effective use of your Azure Cache for Redis instance.


1. Use Standard or Premium tier for production systems. The Basic tier is a single node system with no data replication and no SLA.

2. Remember that Redis is an in-memory data store. 

3. Develop your system such that it can handle connection blips because of patching and failover.

4. Configure your maxmemory-reserved setting to improve system responsiveness under memory pressure conditions.

5. Redis works best with smaller values, so consider chopping up bigger data into multiple keys.

6. Locate your cache instance and your application in the same region. Connecting to a cache in a different region can significantly increase latency and reduce reliability. 

7. Reuse connections. Creating new connections is expensive and increases latency, so reuse connections as much as possible. 

8. Configure your client library to use a connect timeout of at least 15 seconds, giving the system time to connect even under higher CPU conditions.