Azure-docs: CosmosDB Throttling Condition

Created on 18 Feb 2019  Â·  8Comments  Â·  Source: MicrosoftDocs/azure-docs

I have 2000 RU/s set for my single Cosmos DB collection. I have spikes of activity every 3 minutes. I am using the .NET client, so I get the automatic retry using 429 response headers when Cosmos is throttling. However I don't understand how Cosmos decided to throttle.

What period of time is considered for RU consumption vs RU settings when starting and ending throttling?


Document Details

⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

cosmos-dsvc cxp product-question triaged

Most helpful comment

@mack0196 I sent an email to our team to help with your questions, you can also send these questions to [email protected], a broader audience can look at and respond.

All 8 comments

@mack0196 Thanks for the feedback! We are currently investigating and will update you shortly.

Is there a way to get information on the requests that put cosmos into throttle mode?

@mack0196 If you are using a .NET client, there is a response header available that details the RU usage per request (x-ms-request-charge). Please take a look at this Stack Overflow thread that details this very question: How to measure RU in DocumentDB?. That is the most direct means for obtaining this information.

Thanks for that lead. That will help us measure. I am also looking for a way to get cosmos requests that have been processed already. I know I can chart request counts on azure cosmos metrics view, but I cannot find request details on the Azure cosmos view today.

Is there an api for getting past cosmos requests?

@mack0196 Are you looking for the entire document Json for the events that are currently visible to you in the metrics view? By request details, are you looking for the entire message or additional telemetry data about those past requests?
Cosmos DB does have a REST API for accomplishing a wide range of operational tasks: Common tasks using the Azure Cosmos DB REST API where there are both List Documents and Query Documents operations. Perhaps there is something there that meets your needs.

@mack0196 I sent an email to our team to help with your questions, you can also send these questions to [email protected], a broader audience can look at and respond.

@mack0196 We will now proceed to close this thread. If there are further questions regarding this matter, please comment and we will gladly continue the discussion.

Hope this is already addressed, if not, here is some information:

Throughput is provisioned at per second level. So request which consume beyond the limit maximum RU/partition which you can find from diagnostics will result in rate limitation for next set of requests. This throughput at per second is given back as budget in very next second. So retry logic can take care of it in general unless you have the stomping herd mode on where many requests come together and majority get rate limited. in such case you have genuine requirement of increasing the throughput.

WRT requests processed before the throttling, enable the diagnostic log or use the response which comes back in the sdk (200) (not this is not the request header etc.) should be helpful.

Was this page helpful?
0 / 5 - 0 ratings