Merge pull request #286700 from MicrosoftDocs/main

9/13/2024 AM Publish

Author: Taojunshen

articles/azure-app-configuration/faq.yml

@@ -6,7 +6,7 @@ metadata:
   author: zhenlan
   ms.service: azure-app-configuration
   ms.topic: faq
-  ms.date: 02/16/2024
+  ms.date: 09/11/2024
   ms.author: zhenlwa
   ms.custom: references_regions
 title: Azure App Configuration FAQ
@@ -84,8 +84,13 @@ sections:
           
               Standard tier stores are limited to 30,000 requests per hour. Once the hourly quota is exhausted, additional requests may return an HTTP status code 429, indicating too many requests, until the end of the hour. As more requests are sent which are above quota, a higher percentage of them may return status code 429. 
 
-              Premium tier stores have no quota limit on requests.
-          
+              Premium tier stores have no quota limit on requests, ensuring that access to the store is never blocked.
+          - **Throughput**: App Configuration stores in all tiers have a throughput allowance. Requests exceeding this allowance will receive an HTTP status code 429 response.
+              Stores in the Free tier have no guaranteed throughput.
+
+              Stores in the Standard tier allow up to 300 requests per second (RPS) for read requests and up to 60 RPS for write requests.
+
+              Stores in the Premium tier allow up to 450 RPS for read requests and up to 100 RPS for write requests.
           - **Service level agreement**: The Free tier doesn't have an SLA. The Standard tier has an SLA of 99.9% availability and 99.95% availability with geo-replication enabled. The Premium tier has an SLA of 99.9% availability and 99.99% availability with geo-replication enabled.
           - **Features**: All tiers include functionalities, including encryption with Microsoft-managed keys, authentication via access key or Microsoft Entra ID, Azure role-based access control (RBAC), managed identity, service tags, and availability zone redundancy. The Standard and Premium tiers offer more functionalities, including Private Link support, encryption with customer-managed keys, soft delete protection, and geo-replication capability.
           - **Cost**: There's no cost to use a Free tier store.
@@ -98,7 +103,7 @@ sections:
         answer: |
           You can upgrade an App Configuration store at any time, for example, from the Free tier to the Standard or Premium tier, or from the Standard tier to the Premium tier.
           
-          You can’t downgrade an App Configuration store, for example, from the Premium tier to the Standard tier, or from the Standard tier to the Free tier. However, you can create a new store in the desired tier and then [import configuration data into that store](howto-import-export-data.md).
+          You can't downgrade an App Configuration store, for example, from the Premium tier to the Standard tier, or from the Standard tier to the Free tier. However, you can create a new store in the desired tier and then [import configuration data into that store](howto-import-export-data.md).
           
       - question: Where does data stored in App Configuration reside? 
         answer: |
@@ -113,26 +118,10 @@ sections:
           [!INCLUDE [Azure App Configuration availability zones table](../../includes/azure-app-configuration-availability-zones.md)]
 
       - question: Are there any limits on the number of requests made to App Configuration?
-        answer: |
-          Configuration stores in the Free tier are limited to 1,000 requests per day. Configuration stores in the Standard tier may experience temporary throttling when the request rate exceeds 30,000 requests per hour. Configuration stores in the Premium tier have no quota limit on requests.
-          
-          When a store reaches its limit in the Standard tier, it may return HTTP status code 429 for some requests made until the end of the hour. The `retry-after-ms` header in the response gives a suggested wait time (in milliseconds) before retrying the request.
-          
-          If your application regularly experiences HTTP status code 429 responses, consider redesigning it to reduce the number of requests made. For more information, see [how to reduce requests made to App Configuration](./howto-best-practices.md#reduce-requests-made-to-app-configuration).
-          
-      - question: My application receives HTTP status code 429 responses. Why?
-        answer: |
-          You'll receive an HTTP status code 429 response under these circumstances:
-          
-          * Exceeding the daily request limit for a store in the Free tier.
-          * Exceeding the hourly request limit for a store in the standard tier.
-          * Momentary throttling due to a large burst of requests†.
-          * Momentary throttling due to excessive bandwidth usage†.
-          * Attempting to create or modify a key when the storage quota is exceeded.
-          
-          Check the body of the 429 response for the specific reason why the request failed.
-          
-          †A configuration store may experience momentary throttling if it receives a large burst of requests or transfers an excessive volume of data. App Configuration clients, such as the Azure SDK, configuration provider libraries, and Azure Pipelines tasks, automatically retry on throttled requests. For any applications using one of these clients, or a custom client that retries on throttled requests, this momentary throttling should go unnoticed, should it occur.
+        answer: |        
+          App Configuration stores have different request quotas based on their tier. Free tier stores are limited to 1,000 requests per day, Standard tier stores to 30,000 requests per hour, and Premium tier stores have no request limits, ensuring uninterrupted access.
+
+          App Configuration stores have throughput allowances based on their tier. Free tier stores do not have guaranteed throughput. Standard tier stores support up to 300 requests per second (RPS) for read operations and up to 60 RPS for write operations. Premium tier stores support up to 450 RPS for read operations and up to 100 RPS for write operations.
 
       - question: How do I estimate the number of requests my application may send to App Configuration?
         answer: |
@@ -142,10 +131,32 @@ sections:
 
           Secondly, let's estimate the requests for configuration loading/reloading. Your application loads all settings at the startup or whenever a sentinel key change is detected. Each request to App Configuration can retrieve up to 100 key-values, so it will take 10 (=1000/100) requests to load all settings. Given you have 50 application instances, you send 500 (=10x50) total requests when your application restarts or reloads its configuration.
 
-          Finally, let's put it together. Assuming you updated the sentinel key twice within an hour, your App Configuration store will thus receive 7,000 (=6,000+500x2) total requests for that hour. Note that out of these requests, only about 1,000 (=500x2) requests will use the available hourly quota. Update the numbers in this example to match your specific setup and design accordingly so you have a sufficient buffer against the hourly throttling limit. For more information, see [how to reduce requests made to App Configuration](./howto-best-practices.md#reduce-requests-made-to-app-configuration).
+          Finally, let's put it together. Assuming you updated the sentinel key twice within an hour, your App Configuration store will thus receive 7,000 (=6,000+500x2) total requests for that hour. Note that out of these requests, only about 1,000 (=500x2) requests will use the available hourly quota. Update the numbers in this example to match your specific setup and design accordingly so you have a sufficient buffer against the hourly throttling limit.
           
           †Free tier stores do not have frequent, repeated requests excluded from their daily limit.
 
+      - question: My application receives HTTP status code 429 responses. Why?
+        answer: |
+          Your application may receive an HTTP status code 429 response under the following circumstances:
+
+          - Exceeding the daily request quota for a store in the Free tier.
+          - Exceeding the hourly request quota for a store in the Standard tier.
+          - Exceeding the throughput allowance for a store in any tier.
+          - Exceeding the bandwidth allowance for a store in any tier.
+          - Attempting to create or modify a key-value when the storage quota is exceeded.
+          
+          Check the body of the 429 response for the specific reason why the request failed. You can also collect logs for your [App Configuration store in Azure Monitor](./monitor-app-configuration.md) and set up alerts for the *Request Quota Usage* metric.
+
+          Receiving momentary HTTP status code 429 responses usually causes no harm, as App Configuration clients handle them gracefully. However, if your application regularly experiences HTTP status code 429 responses, consider the following options:
+          
+          - **Upgrade your store to the Premium tier**: This tier has no quota limit on requests and has significantly increased storage quota.
+          - **Use App Configuration Providers**: The providers have built-in retry and caching capabilities along with many other resiliency features.
+          - **Use App Configuration SDKs** if your application needs to send write requests. Although the SDKs may not be as feature-rich as providers, they automatically retry on HTTP status code 429 responses.
+          - **Include retry logic in custom clients** if you can't use App Configuration Providers or SDKs. The `retry-after-ms` header in the response provides a suggested wait time (in milliseconds) before retrying the request.
+          - **Distribute requests across multiple client instances**: This helps achieve the maximum throughput from your App Configuration store.
+          - **Reduce requests made to App Configuration**: Follow the guidance to [minimize the number of requests](./howto-best-practices.md#reduce-requests-made-to-app-configuration).
+          - **Improve your application resiliency**: Consider integrating geo-replication to allow failover and load balancing. Check the best practices for [building highly resilient applications](./howto-best-practices.md#building-applications-with-high-resiliency).
+
       - question: Why can't I create an App Configuration store with the same name as one that I just deleted?
         answer: |
           All App Configuration stores in the Standard and Premium tiers have automatically enabled the [soft-delete](concept-soft-delete.md) feature. When a Standard or Premium tier App Configuration store is deleted, its name is reserved for the retention period. To recreate a store with the same name before the retention period expires, you need to [purge the soft-deleted store](howto-recover-deleted-stores-in-azure-app-configuration.md#list-recover-or-purge-a-soft-deleted-app-configuration-store) first, provided the store doesn't have purge protection enabled. If the purge protection is enabled, you must wait for the retention period to elapse. Use the purge function or set a shorter retention period if you often need to recreate a store with the same name. Workflows that require recreating a store with the same name should allow for one hour between purging a configuration store and performing the subsequent create. This recommendation is in place because once a purge is requested the actual cleanup of configuration store resources is performed asynchronously, requiring a bit of extra time to finalize. To avoid any need to wait, workflows that create ephemeral configuration stores are recommended to use unique names.

articles/azure-app-configuration/howto-best-practices.md

@@ -5,7 +5,7 @@ services: azure-app-configuration
 author: zhenlan
 ms.service: azure-app-configuration
 ms.topic: conceptual
-ms.date: 02/20/2024
+ms.date: 09/11/2024
 ms.author: zhenlwa
 ms.custom: "devx-track-csharp, mvc"
 ---
@@ -89,12 +89,10 @@ You can also make your App Configuration data accessible to your application as
 
 Excessive requests to App Configuration can result in throttling or overage charges. To reduce the number of requests made:
 
-* Increase the refresh timeout, especially if your configuration values do not change frequently. Specify a new refresh timeout using the [`SetCacheExpiration` method](/dotnet/api/microsoft.extensions.configuration.azureappconfiguration.azureappconfigurationrefreshoptions.setcacheexpiration).
+* Increase the refresh interval, especially if your configuration values do not change frequently. Specify a new refresh interval using the [`SetCacheExpiration` method](/dotnet/api/microsoft.extensions.configuration.azureappconfiguration.azureappconfigurationrefreshoptions.setcacheexpiration).
 
 * Watch a single *sentinel key*, rather than watching individual keys. Refresh all configuration only if the sentinel key changes. See [Use dynamic configuration in an ASP.NET Core app](enable-dynamic-configuration-aspnet-core.md) for an example.
 
-* Use Azure Event Grid to receive notifications when configuration changes, rather than constantly polling for any changes. For more information, see [Use Event Grid for App Configuration data change notifications](./howto-app-configuration-event.md).
-
 * [Enable geo-replication](./howto-geo-replication.md) of your App Configuration store and spread your requests across multiple replicas. For example, use a different replica from each geographic region for a globally deployed application. Each App Configuration replica has its separate request quota. This setup gives you a model for scalability and enhanced resiliency against transient and regional outages.
 
 ## Importing configuration data into App Configuration

articles/azure-arc/servers/agent-release-notes.md

@@ -2,7 +2,7 @@
 title: What's new with Azure Connected Machine agent
 description: This article has release notes for Azure Connected Machine agent. For many of the summarized issues, there are links to more details.
 ms.topic: overview
-ms.date: 08/12/2024
+ms.date: 09/13/2024
 ms.custom: references_regions
 ---
 
@@ -20,12 +20,30 @@ This page is updated monthly, so revisit it regularly. If you're looking for ite
 > Only Connected Machine agent versions within the last 1 year are officially supported by the product group. Customers should update to an agent version within this window.
 > 
 
-## Version 1.45 - August 2024
+## Version 1.46 - September 2024
 
 Download for [Windows](https://aka.ms/AzureConnectedMachineAgent) or [Linux](manage-agent.md#installing-a-specific-version-of-the-agent)
 
 ### Fixed
 
+- Fixed a bug causing the Guest Config agent to hang in extension creating state when the download of an extension package failed.
+- Fixed a bug where onboarding treated conflicting errors as success.
+
+### New features and enhancements
+
+- Improved error messaging for scenarios with extension installation and enablement blockage in the presence of a sideloaded extension.
+- Increased checks for recovery of sequence number if the previous request failed.
+- Removed casing requirements when reading the proxy from the configuration file.
+- Added supported for Azure Linux 3 (Mariner).
+- Added initial Linux ARM64 architecture support.
+- Added Gateway URL to the output of the show command.
+
+## Version 1.45 - August 2024
+
+Download for [Windows](https://download.microsoft.com/download/0/6/1/061e3c68-5603-4c0e-bb78-2e3fd10fef30/AzureConnectedMachineAgent.msi) or [Linux](manage-agent.md#installing-a-specific-version-of-the-agent)
+
+### Fixed
+
 - Fixed an issue where EnableEnd telemetry would sometimes be sent too soon.
 - Added sending a failed timed-out EnableEnd telemetry log if extension takes longer than the allowed time to complete.
 

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

@@ -51,15 +51,18 @@ sections:
           ### 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).
+            * 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 by using RedisConnection](cache-dotnet-how-to-use-azure-redis-cache.md#connect-to-the-cache-by-using-redisconnection).
             * Set the `ConnectionMultiplexer.ClientName` property to an app instance unique name for diagnostic purposes.
             * Use multiple `ConnectionMultiplexer` instances for custom workloads.
-              * You can follow this model if you have varying load in your application. For example:
+
+              You can follow this model if you have varying loads in your application. For example:  
+
               * You can have one multiplexer for dealing with large keys.
               * 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.
+              * 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 might lead to more streamlined latency per `ConnectionMultiplexer`.
+              
+              Following this guidance might lead to more streamlined latency per `ConnectionMultiplexer`.
           
       - question: |
           What Azure Cache for Redis clients can I use?