Effects
Consistently operating near your RU limit on a Cosmos DB Account will cause an increase in throttled (HTTP 429) operations. Throttling can have a severe impact on application performance as the requests need to be retried. It’s important to note that some request throttling should be expected from Cosmos at any time, even when not operating near the provisioned RU amount; this is just the nature of highly-scalable and distributed databases.
Fixes
The general fix when reaching your RU limit is to provision more RUs for the collections or databases than need it. Before simply adding more RU, you should first ensure that it is the correct course of action.
Optimization
If at all possible, look at the queries you are making through Cosmos to see if optimizations can be made. The amount of RU used in a request is affected by the following properties:
- Item size
- Item indexing
- Number of properties in an item
- Number of indexed properties in an item
- Consistency: strong and bounded staleness consume more RUs when reading
- Number of query results
- Number of query predicates
- Size of both the source set and result set
- Projection of query results
The costs of requests in Request Units does not scale linearly with item size. Azure provides the following table to roughly explain how requests of different size will translate into RU usage:
|
Item Size
|
1 Read
|
1 Write
|
|
1 KB
|
1 RU
|
5 RUs
|
|
100 KB
|
10 RUs
|
50 RUs
|
While it is cheaper to operate on smaller items, for certain data types it may make sense to batch operations together to achieve higher throughput. For example, it takes fewer RU to read an array with 100x 1kb items than to perform 100 read operations to read them separately.
Partitioning
Data stored in Cosmos DB is partitioned to allow for increased redundancy and scalability. Every collection has a defined partition key which is used to organize items into partitions. With a poorly-chosen partition key, you can end up with one or more hot partitions where the majority of requests go to a single partition. This usually results in a very inefficient use of RUs and will make it harder to scale up your throughput. If your data does not inherently contain a good partition key, read up on creating a synthetic partition key or consider storing this data elsewhere.
