Fixed formatting

flang-msft · flang-msft · commit c48c1873edc9 · 2025-04-01T16:54:50.000-07:00
diff --git a/articles/azure-cache-for-redis/cache-management-faq.yml b/articles/azure-cache-for-redis/cache-management-faq.yml
@@ -126,7 +126,7 @@ sections:
  
           ### Recommendation
  
-          Given this information, we strongly recommend that customers set the minimum configuration value for IOCP and WORKER threads to something larger than the default value. We can't give one-size-fits-all guidance on what this value should be because the right value for one application will likely be too high or low for another application. This setting can also affect the performance of other parts of complicated applications, so each customer needs to fine-tune this setting to their specific needs. A good starting place is 200 or 300, then test and tweak as needed.
+          We recommend that customers set the minimum configuration value for IOCP and WORKER threads to something larger than the default value. We can't give one-size-fits-all guidance on this value  because the right value for one application is likely be too high or low for another application. This setting can also affect the performance of other parts of complicated applications.Each customer needs to fine-tune this setting to their specific needs. A good starting place is 200 or 300, then test and tweak as needed.
           
           How to configure this setting:
           
@@ -165,7 +165,7 @@ sections:
             Setting the number of minimum threads in this way isn't recommended because it's a System-wide setting. If you do set it this way, you must restart the application pool for the change to take 
           
           > [!NOTE]
-          > The value specified in this configuration element is a _per-core_ setting. For example, if you have a 4-core machine and want your `minIoThreads`` setting to be 200 at runtime, you would use `processModel minIoThreads="50"`.
+          > The value specified in this configuration element is a _per-core_ setting. For example, if you have a 4-core machine and want your `minIoThreads`` setting to be 200 at runtime, you would use `\<processModel minIoThreads="50"`\>.
           >
           
       - question: |
diff --git a/articles/redis/management-faq.yml b/articles/redis/management-faq.yml
@@ -27,55 +27,55 @@ sections:
       - question: |
           What are some production best practices?
         answer: |
-          * [StackExchange.Redis best practices](#stackexchangeredis-best-practices)
-          * [Configuration and concepts](#configuration-and-concepts)
-          * [Performance testing](#performance-testing)
+          - [StackExchange.Redis best practices](#stackexchangeredis-best-practices)
+          - [Configuration and concepts](#configuration-and-concepts)
+          - [Performance testing](#performance-testing)
 
           ### StackExchange.Redis best practices
 
-          * Set `AbortConnect` to false, then let the ConnectionMultiplexer reconnect automatically.
-          * Use a single, long-lived `ConnectionMultiplexer` instance rather than creating a new connection for each request.
-          * Redis works best with smaller values, so consider chopping up bigger data into multiple keys. In [the Redis discussion](https://groups.google.com/forum/#!searchin/redis-db/size/redis-db/n7aa2A4DZDs/3OeEPHSQBAAJ), 100 kb is considered large. For more information, see [Best practices development](best-practices-development.md#consider-more-keys-and-smaller-values).
-          * Configure your [ThreadPool settings](#important-details-about-threadpool-growth) to avoid timeouts.
-          * Use at least the default connectTimeout of 5 seconds. This interval gives StackExchange.Redis sufficient time to re-establish the connection if there's a network blip.
-          * Be aware of the performance costs associated with different operations you're running. For instance, the `KEYS` command is an O(n) operation and should be avoided. The [redis.io site](https://redis.io/commands/) has details around the time complexity for each operation that it supports. Select each command to see the complexity for each operation.
+          - Set `AbortConnect` to false, then let the ConnectionMultiplexer reconnect automatically.
+          - Use a single, long-lived `ConnectionMultiplexer` instance rather than creating a new connection for each request.
+          - Redis works best with smaller values, so consider chopping up bigger data into multiple keys. In [the Redis discussion](https://groups.google.com/forum/#!searchin/redis-db/size/redis-db/n7aa2A4DZDs/3OeEPHSQBAAJ), 100 kb is considered large. For more information, see [Best practices development](best-practices-development.md#consider-more-keys-and-smaller-values).
+          - Configure your [ThreadPool settings](#important-details-about-threadpool-growth) to avoid timeouts.
+          - Use at least the default connectTimeout of 5 seconds. This interval gives StackExchange.Redis sufficient time to re-establish the connection if there's a network blip.
+          - Be aware of the performance costs associated with different operations you're running. For instance, the `KEYS` command is an O(n) operation and should be avoided. The [redis.io site](https://redis.io/commands/) has details around the time complexity for each operation that it supports. Select each command to see the complexity for each operation.
           
           ### Configuration and concepts
 
-          * Remember that Redis is an **In-Memory** data store. For more information, see [Troubleshoot data loss in Azure Managed Redis](troubleshoot-data-loss.md) so that you're aware of scenarios where data loss can occur.
-          * Develop your system such that it can handle connection blips caused by [patching and failover](failover.md).
+          - Remember that Redis is an _In-Memory_ data store. For more information, see [Troubleshoot data loss in Azure Managed Redis](troubleshoot-data-loss.md) so that you're aware of scenarios where data loss can occur.
+          - Develop your system such that it can handle connection blips caused by [patching and failover](failover.md).
 
           ### Performance testing
 
-          * See [Performance testing with Azure Managed Redis](best-practices-performance.md) for example benchmarks and instructions for running your own performance tests on Azure Managed Redis. 
+          - See [Performance testing with Azure Managed Redis](best-practices-performance.md) for example benchmarks and instructions for running your own performance tests on Azure Managed Redis. 
           
       - question: |
           What are some of the considerations when using common Redis commands?
         answer: |
-          * Avoid using certain Redis commands that take a long time to complete, unless you fully understand the result of these commands. For example, don't run the [KEYS](https://redis.io/commands/keys) command in production. Depending on the number of keys, it could take a long time to return. Each Redis shard is a single-threaded, and it processes commands one at a time. If you have other commands issued after KEYS, they're not be processed until Redis processes the KEYS command. The [redis.io site](https://redis.io/commands/) has details around the time complexity for each operation that it supports. Select each command to see the complexity for each operation.
-          * Key sizes - should I use small key/values or large key/values? It depends on the scenario. If your scenario requires larger keys, you can adjust the ConnectionTimeout, then retry values and adjust your retry logic. From a Redis server perspective, smaller values give better performance.
-          * These considerations don't mean that you can't store larger values in Redis; you must be aware of the following considerations. Latencies are higher. If you have one set of data that is larger and one that is smaller, you can use multiple ConnectionMultiplexer instances. Configure each with a different set of timeout and retry values, as described in the previous [What do the StackExchange.Redis configuration options do](development-faq.yml#what-do-the-stackexchange-redis-configuration-options-do-) section.
+          - Avoid using certain Redis commands that take a long time to complete, unless you fully understand the result of these commands. For example, don't run the [KEYS](https://redis.io/commands/keys) command in production. Depending on the number of keys, it could take a long time to return. Each Redis shard is a single-threaded, and it processes commands one at a time. If you have other commands issued after KEYS, they're not be processed until Redis processes the KEYS command. The [redis.io site](https://redis.io/commands/) has details around the time complexity for each operation that it supports. Select each command to see the complexity for each operation.
+          - Key sizes - should I use small key/values or large key/values? It depends on the scenario. If your scenario requires larger keys, you can adjust the ConnectionTimeout, then retry values and adjust your retry logic. From a Redis server perspective, smaller values give better performance.
+          - These considerations don't mean that you can't store larger values in Redis; you must be aware of the following considerations. Latencies are higher. If you have one set of data that is larger and one that is smaller, you can use multiple ConnectionMultiplexer instances. Configure each with a different set of timeout and retry values, as described in the previous [What do the StackExchange.Redis configuration options do](development-faq.yml#what-do-the-stackexchange-redis-configuration-options-do-) section.
           
       - question: |
           How can I benchmark and test the performance of my cache?
         answer: |
-          * Enable cache diagnostics so you can [monitor](monitor-cache.md) the health of your cache. You can view the metrics in the Azure portal and you can also [download and review](https://github.com/rustd/RedisSamples/tree/master/CustomMonitoring) them using the tools of your choice.
-          * See [Performance testing with Azure Managed Redis](best-practices-performance.md) for example benchmarks and instructions for running your own performance tests on Azure Managed Redis. 
+          - Enable cache diagnostics so you can [monitor](monitor-cache.md) the health of your cache. You can view the metrics in the Azure portal and you can also [download and review](https://github.com/rustd/RedisSamples/tree/master/CustomMonitoring) them using the tools of your choice.
+          - See [Performance testing with Azure Managed Redis](best-practices-performance.md) for example benchmarks and instructions for running your own performance tests on Azure Managed Redis. 
           
       - question: |
           Important details about ThreadPool growth
         answer: |
           The CLR ThreadPool has two types of threads - "Worker" and "I/O Completion Port" (IOCP) threads.
           
-          * Worker threads are used for things like processing the `Task.Run(…)`, or `ThreadPool.QueueUserWorkItem(…)` methods. These threads are also used by various components in the CLR when work needs to happen on a background thread.
-          * IOCP threads are used when asynchronous IO happens, such as when reading from the network.
+          - Worker threads are used for things like processing the `Task.Run(…)`, or `ThreadPool.QueueUserWorkItem(…)` methods. These threads are also used by various components in the CLR when work needs to happen on a background thread.
+          - IOCP threads are used when asynchronous IO happens, such as when reading from the network.
           
           The thread pool provides new worker threads or I/O completion threads on demand (without any throttling) until it reaches the "Minimum" setting for each type of thread. By default, the minimum number of threads is set to the number of processors on a system.
           
           Once the number of existing (busy) threads hits the "minimum" number of threads, the ThreadPool throttles the rate at which it injects new threads to one thread per 500 milliseconds. Typically, if your system gets a burst of work needing an IOCP thread, it processes that work quickly. However, if the burst is more than the configured "Minimum" setting, there's some delay in processing some of the work as the ThreadPool waits for one of two possibilities:
           
-          * An existing thread becomes free to process the work.
-          * No existing thread becomes free for 500 ms and a new thread is created.
+          - An existing thread becomes free to process the work.
+          - No existing thread becomes free for 500 ms and a new thread is created.
           
           Basically, when the number of Busy threads is greater than Min threads, you're likely paying a 500-ms delay before network traffic is processed by the application. Also, when an existing thread stays idle for longer than 15 seconds, it gets cleaned up and this cycle of growth and shrinkage can repeat.
           
@@ -95,11 +95,11 @@ sections:
  
           ### Recommendation
  
-          Given this information, we strongly recommend that customers set the minimum configuration value for IOCP and WORKER threads to something larger than the default value. We can't give one-size-fits-all guidance on what this value should be because the right value for one application can be too high or low for another application. This setting can also affect the performance of other parts of complicated applications, so each customer needs to fine-tune this setting to their specific needs. A good starting place is 200 or 300, then test and tweak as needed.
+          Wwe strongly recommend that customers set the minimum configuration value for IOCP and WORKER threads to something larger than the default value. We can't give one-size-fits-all guidance on  this value because the right value for one application can be too high or low for another application. This setting can also affect the performance of other parts of complicated applications. Each customer needs to fine-tune this setting to their specific needs. A good starting place is 200 or 300, then test and tweak as needed.
           
           How to configure this setting:
           
-          * We recommend changing this setting programmatically by using the [ThreadPool.SetMinThreads (...)](/dotnet/api/system.threading.threadpool.setminthreads#System_Threading_ThreadPool_SetMinThreads_System_Int32_System_Int32_) method in .NET Framework and .NET Core applications.
+          _ We recommend changing this setting programmatically by using the [ThreadPool.SetMinThreads (...)](/dotnet/api/system.threading.threadpool.setminthreads#System_Threading_ThreadPool_SetMinThreads_System_Int32_System_Int32_) method in .NET Framework and .NET Core applications.
           
           For example, in NET Framework, you set it in `Global.asax.cs` in the `Application_Start` method:
               
@@ -125,32 +125,36 @@ sections:
               var builder = WebApplication.CreateBuilder(args);
               // rest of application setup
               ```
-              > [!NOTE]
-              > The value specified by this method is a global setting, affecting the whole AppDomain. For example, if you have a machine with four cores and want to set *minWorkerThreads* and *minIoThreads* to 50 per CPU during run-time, use **ThreadPool.SetMinThreads(200, 200)**.
+            > [!NOTE]
+            > The value specified by this method is a global setting, affecting the whole AppDomain. For example, if you have a machine with four cores and want to set `minWorkerThreads` and `minIoThreads` to 50 per CPU during run-time, use `ThreadPool.SetMinThreads(200, 200)`.
+            >
           
-          * It's also possible to specify the minimum threads setting by using the [*minIoThreads* or *minWorkerThreads* configuration setting](/previous-versions/dotnet/netframework-4.0/7w2sway1(v=vs.100)) under the `<processModel>` configuration element in `Machine.config`. `Machine.config` is typically located at `%SystemRoot%\Microsoft.NET\Framework\[versionNumber]\CONFIG\`. **Setting the number of minimum threads in this way isn't recommended because it's a System-wide setting.**
+          - It's also possible to specify the minimum threads setting by using the `minIoThreads`` or `minWorkerThreads` [configuration setting](/previous-versions/dotnet/netframework-4.0/7w2sway1(v=vs.100)) under the `processModel` configuration element in `Machine.config`. `Machine.config` is typically located at `%SystemRoot%\Microsoft.NET\Framework\[versionNumber]\CONFIG\`. 
+          
+          Setting the number of minimum threads in this way isn't recommended because it's a System-wide setting.
           
             > [!NOTE]
-            > The value specified in this configuration element is a *per-core* setting. For example, if you have a machine with four cores and want your *minIoThreads* setting to be 200 at runtime, you would use `<processModel minIoThreads="50"/>`.
+            > The value specified in this configuration element is a _per-core_ setting. For example, if you have a machine with four cores and want your `minIoThreads` setting to be 200 at runtime, you would use `processModel minIoThreads="50"`.
             >
           
       - question: |
           Enable server GC to get more throughput on the client when using StackExchange.Redis
         answer: |
           Enabling server GC can optimize the client and provide better performance and throughput when using StackExchange.Redis. For more information on server GC and how to enable it, see the following articles:
           
-          * [To enable server GC](/dotnet/framework/configure-apps/file-schema/runtime/gcserver-element)
-          * [Fundamentals of Garbage Collection](/dotnet/standard/garbage-collection/fundamentals)
-          * [Garbage Collection and Performance](/dotnet/standard/garbage-collection/performance)
+          - [To enable server GC](/dotnet/framework/configure-apps/file-schema/runtime/gcserver-element)
+          - [Fundamentals of Garbage Collection](/dotnet/standard/garbage-collection/fundamentals)
+          - [Garbage Collection and Performance](/dotnet/standard/garbage-collection/performance)
           
       - question: |
           Performance considerations around connections
         answer: |
-          Different SKUs might have different limits for client connections, memory, and bandwidth. While each size of cache allows *up to* some number of connections, each connection to Redis has overhead associated with it. An example of such overhead would be CPU and memory usage because of TLS/SSL encryption. The maximum connection limit for a given cache size assumes a lightly loaded cache. If load from connection overhead plus load from client operations exceeds capacity for the system, the cache can experience capacity issues even if you don't exceed the connection limit for the current cache size.
+          Different SKUs might have different limits for client connections, memory, and bandwidth. While each size of cache allows up to some number of connections, each connection to Redis has overhead associated with it. An example of such overhead would be CPU and memory usage because of TLS/SSL encryption. The maximum connection limit for a given cache size assumes a lightly loaded cache. If load from connection overhead plus load from client operations exceeds capacity for the system, the cache can experience capacity issues even if you don't exceed the connection limit for the current cache size.
           
           For more information about the different connections limits for each tier, see [Azure Managed Redis pricing](https://azure.microsoft.com/pricing/details/cache/). For more information about connections and other default configurations, see [Default Redis server configuration](configure.md#default-redis-server-configuration).
           
 additionalContent: |
 
-  ## Next steps
-     Learn about other [Azure Managed Redis FAQs](faq.yml).
+  ## Related content
+  
+  - Learn about other [Azure Managed Redis FAQs](faq.yml).
