formatting

Author: flang-msft

articles/azure-cache-for-redis/cache-best-practices-development.md

@@ -18,11 +18,11 @@ When developing client applications, be sure to consider the relevant best pract
 
 ## Consider more keys and smaller values
 
-Azure Cache for Redis works best with smaller values. Consider dividing bigger chunks of data in to smaller chunks to spread the data over multiple keys. For more information on ideal value size, see this [article](https://stackoverflow.com/questions/55517224/what-is-the-ideal-value-size-range-for-redis-is-100kb-too-large/).
+Azure Cache for Redis works best with smaller values. To spread the data over multiple keys, consider dividing bigger chunks of data in to smaller chunks. For more information on ideal value size, see this [article](https://stackoverflow.com/questions/55517224/what-is-the-ideal-value-size-range-for-redis-is-100kb-too-large/).
 
 ## Large request or response size
 
-A large request/response can cause timeouts. As an example, suppose your timeout value configured on your client is 1 second. Your application requests two keys (for example, 'A' and 'B') at the same time (using the same physical network connection). Most clients support request "pipelining", where both requests 'A' and 'B' are sent one after the other without waiting for their responses. The server sends the responses back in the same order. If response 'A' is large, it can eat up most of the timeout for later requests.
+A large request/response can cause timeouts. As an example, suppose your timeout value configured on your client is 1 second. Your application requests two keys (for example, 'A' and 'B') at the same time (using the same physical network connection). Most clients support request _pipelining_, where both requests 'A' and 'B' are sent one after the other without waiting for their responses. The server sends the responses back in the same order. If response 'A' is large, it can eat up most of the timeout for later requests.
 
 In the following example, request 'A' and 'B' are sent quickly to the server. The server starts sending responses 'A' and 'B' quickly. Because of data transfer times, response 'B' must wait behind response 'A' times out even though the server responded quickly.
 
@@ -42,9 +42,9 @@ Resolutions for large response sizes are varied but include:
 - Optimize your application for a large number of small values, rather than a few large values.
   - The preferred solution is to break up your data into related smaller values.
   - See the post [What is the ideal value size range for redis? Is 100 KB too large?](https://groups.google.com/forum/#!searchin/redis-db/size/redis-db/n7aa2A4DZDs/3OeEPHSQBAAJ) for details on why smaller values are recommended.
-- Increase the size of your VM to get higher bandwidth capabilities
-  - More bandwidth on your client or server VM may reduce data transfer times for larger responses.
-  - Compare your current network usage on both machines to the limits of your current VM size. More bandwidth on only the server or only on the client may not be enough.
+- Increase the size of your virtual machine (VM) to get higher bandwidth capabilities
+  - More bandwidth on your client or server VM can reduce data transfer times for larger responses.
+  - Compare your current network usage on both machines to the limits of your current VM size. More bandwidth on only the server or only on the client might not be enough.
 - Increase the number of connection objects your application uses.
   - Use a round-robin approach to make requests over different connection objects.
 
@@ -62,7 +62,7 @@ Some Redis operations, like the [KEYS](https://redis.io/commands/keys) command,
 
 ## Choose an appropriate tier
 
-Use Standard, Premium, Enterprise, or Enterprise Flash tiers for production systems.  Don't use the Basic tier in production. 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 only meant for simple dev/test scenarios because:
+Use Standard, Premium, Enterprise, or Enterprise Flash tiers for production systems. Don't use the Basic tier in production. 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 only meant for simple dev/test scenarios because:
 
 - they share a CPU core
 - use little memory
@@ -91,7 +91,7 @@ The default version of Redis that is used when creating a cache can change over
 
 ## Specific guidance for the Enterprise tiers
 
-Because the _Enterprise_ and _Enterprise Flash_ tiers are built on Redis Enterprise rather than open-source Redis, there are some differences in development best practices. See [Best Practices for the Enterprise and Enterprise Flash tiers](cache-best-practices-enterprise-tiers.md) for more information.
+Because the _Enterprise_ and _Enterprise Flash_ tiers are built on Redis Enterprise rather than open-source Redis, there are some differences in development best practices. For more information, see [Best Practices for the Enterprise and Enterprise Flash tiers](cache-best-practices-enterprise-tiers.md).
 
 ## Use TLS encryption
 
@@ -101,7 +101,7 @@ If your client library or tool doesn't support TLS, then enabling unencrypted co
 
 ### Azure TLS Certificate Change
 
-Microsoft is updating Azure services to use TLS server certificates from a different set of Certificate Authorities (CAs). This change is rolled out in phases from August 13, 2020 to October 26, 2020 (estimated). Azure is making this change because [the current CA certificates don't  one of the CA/Browser Forum Baseline requirements](https://bugzilla.mozilla.org/show_bug.cgi?id=1649951). The problem was reported on July 1, 2020 and applies to multiple popular Public Key Infrastructure (PKI) providers worldwide. Most TLS certificates used by Azure services today come from the _Baltimore CyberTrust Root_ PKI. The Azure Cache for Redis service will continue to be chained to the Baltimore CyberTrust Root. Its TLS server certificates, however, will be issued by new Intermediate Certificate Authorities (ICAs) starting on October 12, 2020.
+Microsoft is updating Azure services to use TLS server certificates from a different set of Certificate Authorities (CAs). This change is rolled out in phases from August 13, 2020 to October 26, 2020 (estimated). Azure is making this change because [the current CA certificates don't  one of the CA/Browser Forum Baseline requirements](https://bugzilla.mozilla.org/show_bug.cgi?id=1649951). The problem was reported on July 1, 2020 and applies to multiple popular Public Key Infrastructure (PKI) providers worldwide. Most TLS certificates used by Azure services today come from the _Baltimore CyberTrust Root_ PKI. The Azure Cache for Redis service continues to be chained to the Baltimore CyberTrust Root. Its TLS server certificates, however, will be issued by new Intermediate Certificate Authorities (ICAs) starting on October 12, 2020.
 
 > [!NOTE]
 > This change is limited to services in public [Azure regions](https://azure.microsoft.com/global-infrastructure/geographies/). It excludes sovereign (e.g., China) or government clouds.
@@ -110,7 +110,7 @@ Microsoft is updating Azure services to use TLS server certificates from a diffe
 
 #### Does this change affect me?
 
-We expect that most Azure Cache for Redis customers aren't affected by the change. Your application might be affected if it explicitly specifies a list of acceptable certificates, a practice known as “certificate pinning”. If it's pinned to an intermediate or leaf certificate instead of the Baltimore CyberTrust Root, you should take immediate actions to change the certificate configuration.
+Most Azure Cache for Redis customers aren't affected by the change. Your application might be affected if it explicitly specifies a list of acceptable certificates, a practice known as _certificate pinning_. If it's pinned to an intermediate or leaf certificate instead of the Baltimore CyberTrust Root, you should take immediate actions to change the certificate configuration.
 
 Azure Cache for Redis doesn't support [OCSP stapling](https://docs.redis.com/latest/rs/security/certificates/ocsp-stapling/).
 

articles/azure-cache-for-redis/cache-development-faq.yml

@@ -1,7 +1,7 @@
 ### YamlMime:FAQ
 metadata:
   title: Azure Cache for Redis development FAQs
-  description: Learn the answers to common questions that help you develop for Azure Cache for Redis
+  description: Learn the answers to common questions that help you develop for Azure Cache for Redis.
   author: flang-msft
   ms.author: franlanglois
   ms.service: cache
@@ -43,12 +43,12 @@ sections:
           
           Usually the default values of the client are sufficient. You can fine-tune the options based on your workload.
           
-          * **Retries**
+           ### Retries
             * For ConnectRetry and ConnectTimeout, the general guidance is to fail fast and retry again. This guidance is based on your workload and how much time---on average---it takes for your client to issue a Redis command and receive a response.
             * Let StackExchange.Redis automatically reconnect instead of checking connection status and reconnecting yourself. **Avoid using the ConnectionMultiplexer.IsConnected property**.
             * Snowballing - you might run into an issue where you're retrying and the retries snowball and never recover. If snowballing occurs, consider using an exponential backoff retry algorithm as described in [Retry general guidance](/azure/architecture/best-practices/transient-faults) published by the Microsoft Patterns & Practices group.
             
-          * **Timeout values**
+          ###Timeout values
             * Consider your workload and set the values to match. If you're storing large values, set the timeout to a higher value.
             * Set `AbortOnConnectFail` to false and let StackExchange.Redis reconnect for you.
             * Use a single, long-lived `ConnectionMultiplexer` instance rather than creating a new connection for each request. For an example of how to manage a connection, see the `RedisConnection`` class in [Connect to the cache with RedisConnection](cache-dotnet-how-to-use-azure-redis-cache.md#connect-to-the-cache-with-redisconnection).
@@ -59,7 +59,7 @@ sections:
               * You can have one multiplexer for dealing with small keys.
               * You can set different values for connection timeouts and retry logic for each ConnectionMultiplexer that you use.
               * Set the `ClientName` property on each multiplexer to help with diagnostics.
-              * This guidance may lead to more streamlined latency per `ConnectionMultiplexer`.
+              * This guidance might lead to more streamlined latency per `ConnectionMultiplexer`.
           
       - question: |
           What Azure Cache for Redis clients can I use?
@@ -90,7 +90,7 @@ sections:
                 }
             }
             ```
-          
+                    
           You can optionally configure a [redis.conf](https://redis.io/topics/config) file to more closely match the [default cache settings](cache-configure.md#default-redis-server-configuration) for your online Azure Cache for Redis if you want.
           
       - question: |
@@ -110,14 +110,14 @@ sections:
                `redis-cli -h <Azure Cache for Redis name>.redis.cache.windows.net -a <key>`
           
           > [!NOTE]
-          > The Redis command-line tools do not work with the TLS port, but you can use a utility such as `stunnel` to securely connect the tools to the TLS port by following the directions in the [How to use the Redis command-line tool with Azure Cache for Redis](./cache-how-to-redis-cli-tool.md) article.
+          > The Redis command-line tools don't work with the TLS port, but you can use a utility such as `stunnel` to securely connect the tools to the TLS port by following the directions in the [How to use the Redis command-line tool with Azure Cache for Redis](./cache-how-to-redis-cli-tool.md) article.
           >
           >
           
       - question: |
           Why doesn't Azure Cache for Redis have an MSDN class library reference?
         answer: |
-          Microsoft Azure Cache for Redis is based on the popular open-source in-memory data store, Redis. It can be accessed by a wide variety of [Redis clients](https://redis.io/docs/connect/clients/) for many programming languages. Each client has its own API that makes calls to the Azure Cache for Redis instance using [Redis commands](https://redis.io/commands).
+          Microsoft Azure Cache for Redis is based on the popular open-source in-memory data store, Redis. You can use a wide variety of [Redis clients](https://redis.io/docs/connect/clients/) for many programming languages. Each client has its own API that makes calls to the Azure Cache for Redis instance using [Redis commands](https://redis.io/commands).
           
           Because each client is different, you can't find one centralized class reference on MSDN. Each client maintains its own reference documentation. Besides the reference documentation, there are several tutorials showing how to get started with Azure Cache for Redis using different languages and cache clients. To access these tutorials, see [How to use Azure Cache for Redis](cache-dotnet-how-to-use-azure-redis-cache.md) and it's sibling articles in the table of contents.
           
@@ -131,7 +131,7 @@ sections:
           >
           > `session.save_path = "tcp://mycache.redis.cache.windows.net:6379?auth=<url encoded primary or secondary key here>";`
           >
-          > If the key is not URL encoded, you may receive an exception with a message like: `Failed to parse session.save_path`
+          > If the key isn't URL encoded, you might receive an exception with a message like: `Failed to parse session.save_path`
           >
           
           For more information about using Azure Cache for Redis as a PHP session cache with the PhpRedis client, see [PHP Session handler](https://github.com/phpredis/phpredis#php-session-handler).
@@ -142,7 +142,7 @@ sections:
           Redis Databases are just a logical separation of data within the same Redis instance. The cache memory is shared between all the databases and actual memory consumption of a given database depends on the keys/values stored in that database. For example, a C6 cache has 53 GB of memory, and a P5 has 120 GB. You can choose to put all 53 GB / 120 GB into one database or you can split it up between multiple databases. 
           
           > [!NOTE]
-          > When using a Premium Azure Cache for Redis with clustering enabled, only database 0 is available. This limitation is an intrinsic Redis limitation and is not specific to Azure Cache for Redis.
+          > When using a Premium Azure Cache for Redis with clustering enabled, only database 0 is available. This limitation is an intrinsic Redis limitation and isn't specific to Azure Cache for Redis.
           
 additionalContent: |