update throttling

Author: tfitzmac

articles/azure-resource-manager/resource-manager-request-limits.md

@@ -10,9 +10,9 @@ ms.custom: seodec18
 ---
 # Throttling Resource Manager requests
 
-This article helps you understand how Azure Resource Manager throttles requests. It shows you how to determine the remaining requests you have before reaching the limit, and how to respond when you've reached the limit.
+This article describes how Azure Resource Manager throttles requests. It shows you how to track the number of requests that remain before reaching the limit, and how to respond when you've reached the limit.
 
-Throttling happens at two levels. Azure Resource Manager throttles requests for the subscription and tenant. The resource provider throttles requests for its operations. The following image shows how throttling is applied as a request goes from the user to Azure Resource Manager and the resource provider.
+Throttling happens at two levels. Azure Resource Manager throttles requests for the subscription and tenant. If the request is under the throttling limits for the subscription and tenant, Resource Manager routes the request to the resource provider. The resource provider applies throttling limits that are tailored to its operations. The following image shows how throttling is applied as a request goes from the user to Azure Resource Manager and the resource provider.
 
 ![Request throttling](./media/resource-manager-request-limits/request-throttling.svg)
 
@@ -32,13 +32,15 @@ The default throttling limits per hour are shown in the following table.
 
 These limits are scoped to the security principal (user or application) making the requests and the subscription ID or tenant ID. If your requests come from more than one security principal, your limit across the subscription or tenant is greater than 12,000 and 1,200 per hour.
 
-These limits apply to each Azure Resource Manager instance. There are multiple instances in every Azure region, and Azure Resource Manager is deployed to all Azure regions.  So, in practice, limits are effectively much higher than these limits, as user requests are usually serviced by many different instances. A resource provider might receive more requests than the stated default limits. This condition is important when assessing [resource provider limits](#resource-provider-limits).
+These limits apply to each Azure Resource Manager instance. There are multiple instances in every Azure region, and Azure Resource Manager is deployed to all Azure regions.  So, in practice, the limits are higher than these limits. The requests from a user are usually handled by different instances of Azure Resource Manager.
 
-These limits can be raised per operation through a support request. For the request to be accepted, the resource provider for the operation must support a higher limit. The limit can be either global or per subscription.  
+You can increase the throttling limit per operation through a support request. For the request to be accepted, the resource provider for the operation must support a higher limit. The limit can be either global or per subscription.  
 
 ## Resource provider limits
 
-Resource providers apply their own throttling limits. This section discusses the throttling limits of some widely-used resource providers.
+Resource providers apply their own throttling limits. Because Resource Manager throttles by principal ID and by instance of Resource Manager, the resource provider might receive more requests than the default limits in the previous section.
+
+This section discusses the throttling limits of some widely used resource providers.
 
 ### Storage throttling
 
@@ -65,6 +67,12 @@ For checking virtual machine instances within a virtual machine scale set, use t
 
 Azure Resource Graph limits the number of requests to its operations. The steps in this article to determine the remaining requests and how to respond when the limit is reached also apply to Resource Graph. However, Resource Graph sets its own limit and reset rate. For more information, see [Throttle in Azure Resource Graph](../governance/resource-graph/overview.md#throttling).
 
+## Error code
+
+When you reach the limit, you receive the HTTP status code **429 Too many requests**. The response includes a **Retry-After** value, which specifies the number of seconds your application should wait (or sleep) before sending the next request. If you send a request before the retry value has elapsed, your request isn't processed and a new retry value is returned.
+
+Some resource providers return 429 to report a temporary problem. The problem could be an overload condition that isn't directly caused by your request. Or, it could represent a temporary error about the state of the target resource or dependent resource. For example, the network resource provider returns 429 with the **RetryableErrorDueToAnotherOperation** error code when the target resource is locked by another operation. To determine if the error comes from throttling or a temporary condition, view the error details in the response.
+
 ## Remaining requests
 
 You can determine the number of remaining requests by examining response headers. Read requests return a value in the header for the number of remaining read requests. Write requests include a value for the number of remaining write requests. The following table describes the response headers you can examine for those values:
@@ -80,12 +88,6 @@ You can determine the number of remaining requests by examining response headers
 | x-ms-ratelimit-remaining-tenant-resource-requests |Tenant scoped resource type requests remaining.<br /><br />This header is only added for requests at tenant level, and only if a service has overridden the default limit. Resource Manager adds this value instead of the tenant reads or writes. |
 | x-ms-ratelimit-remaining-tenant-resource-entities-read |Tenant scoped resource type collection requests remaining.<br /><br />This header is only added for requests at tenant level, and only if a service has overridden the default limit. |
 
-## Error code
-
-When you reach the limit, you receive the HTTP status code **429 Too many requests**. The response includes a **Retry-After** value, which specifies the number of seconds your application should wait (or sleep) before sending the next request. If you send a request before the retry value has elapsed, your request isn't processed and a new retry value is returned.
-
-Some resource providers return 429 to report a temporary problem. The problem could be an overload condition that isn't directly caused by your request. Or, it could represent a temporary error about the state of the target resource or dependent resource. For example, the network resource provider returns 429 with the **RetryableErrorDueToAnotherOperation** error code when the target resource is locked by another operation. To determine if the error comes from throttling or a temporary condition, view the error details in the response.
-
 ## Retrieving the header values
 
 Retrieving these header values in your code or script is no different than retrieving any header value.