Note
Access to this page requires authorization. You can try signing in or changing directories.
Access to this page requires authorization. You can try changing directories.
In this article, we discuss concepts of when and why to scale your Azure Managed Redis cache.
Scale before load is too high
Scale your cache proactively while it still has spare CPU and memory capacity. When you scale, Azure Managed Redis migrates your data to new nodes and shards. This data migration, along with communication and coordination between nodes, needs CPU, memory, and network bandwidth on the same nodes that serve your client requests. If CPU or memory usage is too high, the busy Redis server doesn't have enough resources to both serve your workload and complete the scaling operation. Scaling under these conditions can increase latency, cause timeouts and connection errors, and make the scaling operation take much longer to complete or fail.
To minimize the effect of scaling on your workload:
- Create alerts on the CPU and Used Memory Percentage metrics so you can plan to scale before your cache gets close to saturation. If either metric is consistently above 75% during peak traffic, plan to scale.
- Schedule the scaling operation during a period of low to moderate traffic, such as off-peak hours.
- Don't use scaling as an immediate mitigation when CPU or memory usage is already close to saturation. First, reduce CPU and memory usage. For example, pause nonessential workloads such as batch jobs, avoid long-running commands, or delete keys that you no longer need. Then, scale when traffic and resource usage are lower.
For more information, see When to scale.
Minimizing your data helps scaling complete quicker
If preserving the data in the cache isn't a requirement, consider flushing the data before scaling. Flushing the cache helps the scaling operation complete more quickly so the new capacity is available sooner.
Using TLS/SSL
If you're using TLS/SSL, the CPU experiences higher overhead for the cache to handle encryption. This increased overhead is especially significant if you're using many connections or if you're using an instance with fewer vCPUs. Consider scaling up to a higher tier if you need more performance.