Edits to new content, acrolinx, linter fixes

Author: flang-msft

articles/azure-cache-for-redis/cache-best-practices-enterprise-tiers.md

@@ -1,11 +1,11 @@
 ---
 title: Best practices for the Enterprise tiers
 titleSuffix: Azure Cache for Redis
-description: Learn the best practices when using the high performance Azure Cache for Redis Enterprise and Enterprise Flash tiers
+description: Learn the best practices when using the high performance Azure Cache for Redis Enterprise and Enterprise Flash tiers.
 author: flang-msft
 ms.service: cache
 ms.topic: conceptual
-ms.date: 09/26/2023
+ms.date: 05/21/2024
 ms.author: franlanglois
 ---
 
@@ -29,7 +29,7 @@ Conversely, the opposite recommendation is true for the Basic, Standard, and Pre
 
 ## Sharding and CPU utilization
 
-In the Basic, Standard, and Premium tiers of Azure Cache for Redis, determining the number of virtual CPUs (vCPUs) utilized is straightforward. Each Redis node runs on a dedicated VM. The Redis server process is single-threaded, utilizing one vCPU on each primary and each replica node. The other vCPUs on the VM are still used for other activities, such as workflow coordination for different tasks, health monitoring, and TLS load, among others.
+In the Basic, Standard, and Premium tiers of Azure Cache for Redis, determining the number of virtual CPUs (vCPUs) utilized is straightforward. Each Redis node runs on a dedicated virtual machine (VM). The Redis server process is single-threaded, utilizing one vCPU on each primary and each replica node. The other vCPUs on the VM are still used for other activities, such as workflow coordination for different tasks, health monitoring, and TLS load, among others.
 
 When you use clustering, the effect is to spread data across more nodes with one shard per node. By increasing the number of shards, you linearly increase the number of vCPUs you use, based on the number of shards in the cluster.
 
@@ -38,19 +38,21 @@ Redis Enterprise, on the other hand, can use multiple vCPUs for the Redis instan
 The tables show the number of vCPUs used for the primary shards, not the replica shards. Shards don't map one-to-one to the number of vCPUs. The tables only illustrate vCPUs, not shards. Some configurations use more shards than available vCPUs to boost performance in some usage scenarios.
 
 ### E1
+
 |Capacity|Effective vCPUs|
 |---:|---:|
 | 2 | 1 (burstable) |
 
-
 ### E5
+
 |Capacity|Effective vCPUs|
 |---:|---:|
 | 2 | 1 |
 | 4 | 2 |
 | 6 | 6 |
 
 ### E10
+
 |Capacity|Effective vCPUs|
 |---:|---:|
 | 2 | 2 |
@@ -90,6 +92,7 @@ The tables show the number of vCPUs used for the primary shards, not the replica
 |10|30|
 
 ### E200
+
 |Capacity|Effective vCPUs|
 |---:|---:|
 |2|30|
@@ -99,6 +102,7 @@ The tables show the number of vCPUs used for the primary shards, not the replica
 |10|120|
 
 ### E400
+
 |Capacity|Effective vCPUs|
 |---:|---:|
 |2|60|
@@ -146,24 +150,30 @@ You might also see `CROSSSLOT` errors with Enterprise clustering policy. Only th
 In Active-Active databases, multi-key write commands (`DEL`, `MSET`, `UNLINK`) can only be run on keys that are in the same slot. However, the following multi-key commands are allowed across slots in Active-Active databases: `MGET`, `EXISTS`, and `TOUCH`. For more information, see [Database clustering](https://docs.redis.com/latest/rs/databases/durability-ha/clustering/#multikey-operations).
 
 ## Enterprise Flash Best Practices
-The Enterprise Flash tier utilizes both NVMe Flash storage and RAM. Because Flash storage is lower cost, using the Enterprise Flash tier allows you to trade off some performance for price efficiency. 
 
-On Enterprise Flash instances, 20% of the cache space is on RAM, while the other 80% uses Flash storage. All of the _keys_ are stored on RAM, while the _values_ can be stored either in Flash storage or RAM. The location of the values is determined intelligently by the Redis software. "Hot" values that are accessed fequently are stored on RAM, while "Cold" values that are less commonly used are kept on Flash. Before data is read or written, it must be moved to RAM, becoming "Hot" data. 
+The Enterprise Flash tier utilizes both NVMe Flash storage and RAM. Because Flash storage is lower cost, using the Enterprise Flash tier allows you to trade off some performance for price efficiency.
 
-Because Redis will optmize for the best performance, the instance will first fill up the available RAM before adding items to Flash storage. This has a few implications for performance:
-- When testing with low memory usage, performance and latency may be significantly better than with a full cache instance because only RAM is being used.
-- As you write more data to the cache, the proportion of data in RAM compared to Flash storage will decrease, typically causing latency and throughput performance to decrease as well.
+On Enterprise Flash instances, 20% of the cache space is on RAM, while the other 80% uses Flash storage. All of the _keys_ are stored on RAM, while the _values_ can be stored either in Flash storage or RAM. The Redis software intelligently determines the location of the values. _Hot_ values that are accessed frequently are stored on RAM, while _Cold_ values that are less commonly used are kept on Flash. Before data is read or written, it must be moved to RAM, becoming "Hot" data.
+
+Because Redis optimizes for the best performance, the instance first fills up the available RAM before adding items to Flash storage. Filly RAM first has a few implications for performance:
+
+- Better performance and lower latency can occur when testing with low memory usage. Testing with a full cache instance can yield lower performance because only RAM is being used in the low memory usage testing phase.
+- As you write more data to the cache, the proportion of data in RAM compared to Flash storage decreases, typically causing latency and throughput performance to decrease as well.
 
 ### Workloads well-suited for the Enterprise Flash tier
+
 Workloads that are likely to run well on the Enterprise Flash tier often have the following characteristics:
+
 - Read heavy, with a high ratio of read commands to write commands.
-- Access is focused on a subset of keys which are used much more frequently than the rest of the dataset.
-- Relatively large values in comparison to key names. (Since key names are always stored in RAM, this can become a bottleneck for memory growth.)
+- Access is focused on a subset of keys that are used much more frequently than the rest of the dataset.
+- Relatively large values in comparison to key names. (Because key names are always stored in RAM, large values can become a bottleneck for memory growth.)
+
+### Workloads that aren't well-suited for the Enterprise Flash tier
 
-### Workloads that are not well-suited for the Enterprise Flash tier
 Some workloads have access characteristics that are less optimized for the design of the Flash tier:
+
 - Write heavy workloads.
-- Random or uniform data access paterns across most of the dataset.
+- Random or uniform data access patterns across most of the dataset.
 - Long key names with relatively small value sizes.
 
 ## Handling Region Down Scenarios with Active Geo-Replication
@@ -187,7 +197,7 @@ Many customers want to use persistence to take periodic backups of the data on t
 
 ## E1 SKU Limitations
 
-The E1 SKU is intented primarily for dev/test scenarios. It runs on smaller [burstable VMs](../virtual-machines/b-series-cpu-credit-model/b-series-cpu-credit-model.md), which offers variable performance based on how much CPU is consumed. Unlike other Enterprise SKU offerings, it is not possible to scale the E1 SKU out, although it is still possible to scale up to a larger SKU. The E1 SKU also does not support [active geo-replication](cache-how-to-active-geo-replication.md). 
+The E1 SKU is intended for dev/test scenarios, primarily. E1 runs on smaller [burstable VMs](../virtual-machines/b-series-cpu-credit-model/b-series-cpu-credit-model.md). Burstable VMs offer variable performance based on how much CPU is consumed. Unlike other Enterprise SKU offerings, you can't _scale out_ the E1 SKU, although it's still possible to _scale up_ to a larger SKU. The E1 SKU also doesn't support [active geo-replication](cache-how-to-active-geo-replication.md).
 
 ## Related content
 

articles/azure-cache-for-redis/cache-how-to-active-geo-replication.md

@@ -31,12 +31,13 @@ The Premium tier of Azure Cache for Redis offers a version of geo-replication ca
 ## Active geo-replication prerequisites
 
 There are a few restrictions when using active geo replication:
+
 - Only the [RediSearch](cache-redis-modules.md#redisearch) and [RedisJSON](cache-redis-modules.md#redisjson) modules are supported
 - On the _Enterprise Flash_ tier, only the _No Eviction_ eviction policy can be used. All eviction policies are supported on the _Enterprise_ tier.
 - Data persistence isn't supported because active geo-replication provides a superior experience.
 - You can't add an existing (that is, running) cache to a geo-replication group. You can only add a cache to a geo-replication group when you create the cache.
-- All caches within a geo-replication group must have the same configuration. For example, all caches must have the same SKU, capacity, eviction policy, clustering policy, modules, and TLS setting. 
-- You can't use the `FLUSHALL` and `FLUSHDB` Redis commands when using active geo-replication. Prohibiting the commands prevents unintended deletion of data. Use the [flush control plane operation](#flush-operation) instead.
+- All caches within a geo-replication group must have the same configuration. For example, all caches must have the same SKU, capacity, eviction policy, clustering policy, modules, and TLS setting.
+- You can't use the `FLUSHALL` and `FLUSHDB` Redis commands when using active geo-replication. Prohibiting the commands prevents unintended deletion of data. Use the [flush operation](#flush-operation) from the portal instead.
 - The E1 SKU does not support active geo-replication.
 
 ## Create or join an active geo-replication group
@@ -137,16 +138,16 @@ As before, you need to list both _Cache1_ and _Cache2_ using the `-LinkedDatabas
 
 ## Flush operation
 
-Due to the potential for inadvertent data loss, you can't use the `FLUSHALL` and `FLUSHDB` Redis commands with any cache instance residing in a geo-replication group. Instead, use the **Flush Cache(s)** button located at the top of the **Active geo-replication** working pane. 
+Due to the potential for inadvertent data loss, you can't use the `FLUSHALL` and `FLUSHDB` Redis commands with any cache instance residing in a geo-replication group. Instead, use the **Flush Cache(s)** button located at the top of the **Active geo-replication** working pane.
 
 :::image type="content" source="media/cache-how-to-active-geo-replication/cache-active-flush.png" alt-text="Screenshot showing Active geo-replication selected in the Resource menu and the Flush cache feature has a red box around it.":::
 
 ### Flush caches using Azure CLI or PowerShell
 
-The Azure CLI and PowerShell can also be used to trigger a flush operation. For more information on using Azure CLI, see [az redisenterprise database flush](/cli/azure/redisenterprise#az-redisenterprise-database-flush). For more information on using PowerShell, see [Invoke-AzRedisEnterpriseCacheDatabaseFlush](/powershell/module/az.redisenterprisecache/invoke-azredisenterprisecachedatabaseflush). 
+The Azure CLI and PowerShell can also be used to trigger a flush operation. For more information on using Azure CLI, see [az redisenterprise database flush](/cli/azure/redisenterprise#az-redisenterprise-database-flush). For more information on using PowerShell, see [Invoke-AzRedisEnterpriseCacheDatabaseFlush](/powershell/module/az.redisenterprisecache/invoke-azredisenterprisecachedatabaseflush).
 
 > [!IMPORTANT]
-> Be careful when using the **Flush Caches** feature. Selecting the button removes all data from the current cache and from ALL linked caches in the geo-replication group. 
+> Be careful when using the **Flush Caches** feature. Selecting the button removes all data from the current cache and from ALL linked caches in the geo-replication group.
 >
 
 Manage access to the feature using [Azure role-based access control](../role-based-access-control/overview.md). Only authorized users should be given access to flush all caches.
@@ -155,7 +156,5 @@ Manage access to the feature using [Azure role-based access control](../role-bas
 
 Learn more about Azure Cache for Redis features.
 
-* [Azure Cache for Redis service tiers](cache-overview.md#service-tiers)
-* [High availability for Azure Cache for Redis](cache-high-availability.md)
-
-
+- [Azure Cache for Redis service tiers](cache-overview.md#service-tiers)
+- [High availability for Azure Cache for Redis](cache-high-availability.md)