{"id":6314,"date":"2023-05-31T08:10:02","date_gmt":"2023-05-31T15:10:02","guid":{"rendered":"https:\/\/devblogs.microsoft.com\/cosmosdb\/?p=6314"},"modified":"2023-11-13T07:02:01","modified_gmt":"2023-11-13T15:02:01","slug":"introducing-priority-based-execution-in-azure-cosmos-db-preview","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/cosmosdb\/introducing-priority-based-execution-in-azure-cosmos-db-preview\/","title":{"rendered":"Introducing priority-based execution in Azure Cosmos DB (preview)"},"content":{"rendered":"

The problem<\/span>\u00a0<\/span>\u00a0<\/span><\/h3>\n

Azure Cosmos DB is a fast and flexible database service that can handle massive amounts of data and scale elastically. However, sometimes you may encounter situations where your application sends more requests than the configured throughput (RU\/s) of your container. In such cases, <\/span>Azure <\/span>Cosmos DB will throttle some of the requests and return a 429 status code with a retry-after header.<\/span>\u00a0<\/span><\/p>\n

This situation can be frustrating and can lead to degradation of application performance and even revenue loss.\u00a0<\/span>\u00a0<\/span><\/p>\n

The Solution<\/span>\u00a0<\/span><\/h3>\n

What if there was a way to overcome this situation without incurring the extra cost of provisioning higher RU\/sec?<\/span>\u00a0<\/span><\/p>\n

Priority-based execution is a capability which allows users to specify priority for the request sent to <\/span>Azure <\/span>Cosmos DB. Based on the priority specified by the user, if there are more requests than the configured RU\/s in a second, then <\/span>Azure <\/span>Cosmos DB will throttle low priority requests to allow high priority requests to execute.<\/span>\u00a0<\/span><\/p>\n

This capability allows a user to perform more important tasks while delaying less important tasks when there are a higher number of requests than what a container with configured RU\/s can handle at a given time. Less important tasks will be continuously retried by any client using an SDK based on the <\/span>retry policy<\/span><\/a> configured.<\/span>\u00a0<\/span><\/p>\n

How does priority-based execution work?<\/span><\/b>\u00a0<\/span><\/h3>\n

Let’s take an example of an e-commerce application that uses Azure Cosmos DB as its backend. Suppose the application has two types of requests: one for displaying product information to users and another for updating the product catalog. <\/span>\u00a0<\/span><\/p>\n

Let’s say you have provisioned 400 RU\/sec on the product container. During peak hours, 400 RPS requests come in for displaying product information, while 150 RPS requests come in for catalog updates.<\/span>\u00a0<\/span><\/p>\n

For simplicity, let’s assume that each request consumes 1 RU\/sec for each transaction. We can observe how Azure Cosmos DB behaves in such a scenario using the metrics below.<\/span>\u00a0<\/span><\/p>\n

\"Accepted<\/a><\/p>\n

 <\/p>\n

\"Throttled<\/a><\/p>\n

As you can observe from the above metrics, both product information requests and catalog update requests are throttled when the consumption of the container is above 400 RU\/s. This is fair since a provisioned resource can\u2019t accept load beyond its configured capacity. However, for customers these kinds of scenarios may not be favorable. When product information display requests are not completed, customers can\u2019t see product information and therefore can\u2019t make purchases. <\/span>\u00a0<\/span><\/p>\n

Seeing it in operation\u00a0<\/span><\/b>\u00a0<\/span><\/h4>\n

Let\u2019s see how priority-based execution can solve this problem.<\/span>\u00a0<\/span><\/p>\n

The product display requests are more critical than the catalog updates, so logically, they should be given higher priority. The application can use the following code snippet to set the priority of each request using the SDK.<\/span>\u00a0<\/span><\/p>\n

Using Mircosoft.Azure.Cosmos.PartitionKey;\u00a0\r\nUsing Mircosoft.Azure.Cosmos.PriorityLevel;\u00a0\r\n\r\n\/\/update products catalog\u00a0\u00a0\r\nRequestOptions catalogRequestOptions = new ItemRequestOptions{PriorityLevel = PriorityLevel.Low};\u00a0\r\n\r\nPartitionKey pk = new PartitionKey(\u201cproductId1\u201d);\u00a0\r\nItemResponse<Product> catalogResponse = await this.container.CreateItemAsync<Product>(product1, pk, requestOptions);\u00a0\r\n\r\n\/\/Display product information to user\u00a0\r\nRequestOptions getProductRequestOptions = new ItemRequestOptions{PriorityLevel = PriorityLevel.High};\u00a0\r\n\r\nstring id = \u201cproductId2\u201d;\u00a0\r\nPartitionKey pk = new PartitionKey(id);\u00a0\r\n\r\nItemResponse<Product> productResponse = await this.container.ReadItemAsync< Product>(id, pk, getProductRequestOptions);\u00a0<\/code><\/pre>\n
Let\u2019s observe the behavior of Azure Cosmos DB for a similar workload with priority-based execution enabled using the metrics below.<\/span>\u00a0<\/span><\/p>\n
\"Accepted<\/a><\/p>\n
 <\/p>\n
\"Throttled<\/a><\/p>\n
With priority-based execution, when the total consumption of the container exceeds the configured RU\/s, Azure Cosmos DB first throttles low-priority requests, allowing high-priority requests to execute in a high load situation.\u00a0 This helps users execute important requests and improve the customer experience without overprovisioning RU\/s in the container and incurring extra costs.<\/span>\u00a0<\/span><\/p>\n
 <\/p>\n
Key Benefits<\/span>\u00a0<\/span><\/h3>\n