問題描述
cosmosDB RU 吞吐量如何強制執行 (How is cosmosDB RU throughput enforced)
我有一個設置為 400 RU/s 的 cosmosGB gremlin API。如果我必須運行一個需要 800 RU 的查詢，這是否意味著該查詢需要 2 秒才能執行？如果我將吞吐量增加到 1600 RU/s，這個查詢會在半秒內執行嗎？通過使用 RU，我沒有看到查詢性能有任何顯著變化。
參考解法
方法 1:
As I explained in a different, but somewhat related answer here, Request Units are allocated on a per‑second basis. In the event a given query will cost more than the number of Request Units available in that one‑second window:
- The query will be executed
- You will now be in "debt" by the overage in Request Units
- You will be throttled until your "debt" is paid off
</ul>
Let's say you had 400 RU/sec, and you executed a query that cost 800 RU. It would complete, but then you'd be in debt for around 2 seconds (400 RU per second, times two seconds). At this point, you wouldn't be throttled anymore.
The speed in which a query executes does not depend on the number of RU allocated. Whether you had 1,000 RU/second OR 100,000 RU/second, a query would run in the same amount of time (aside from any throttle time preventing the query from running initially). So, aside from throttling, your 800 RU query would run consistently, regardless of RU count.
方法 2:
A single query is charged a given amount of request units, so it's not quite accurate to say "query needs 800 RU/s". A 1KB doc read is 1 RU, and writing is more expensive starting around 10 RU each. Generally you should avoid any requests that would individually be more than say 50, and that is probably high. In my experience, I try to keep the individual charge for each operation as low as possible, usually under 20‑30 for large list queries.
The upshot is that 400/s is more than enough to at least complete 1 query. It's when you have multiple attempts that combine for overage in the timespan that Cosmos tells you to wait some time before being allowed to succeed again. This is dynamic and based on a more or less black box formula. It's not necessarily a simple division of allowance by charge, and no individual request would be faster or slower based on the limit.
You can see if you're getting throttled by inspecting the response, or monitor by checking the Azure dashboard metrics.
(by Michael Scott、David Makogon、Noah Stahl)