One of the major questions, while provisioning an Azure DocumentDB collection is “How many Resource Units should I provision for the collection”?
Request Units (RUs), of course, is a measure of guaranteed throughput of the Azure DocumentDB Collection. While provisioning these collections, the minimum limit appears to be 400 RUs.
So I was curious about how this would measure up in a real world scenario. Consider, the speakers and sessions signup module for a Codecamp. A sample signup session would generate data that resembled something similar to the sample JSON data listed below.
“FullName”: “Santosh Hari”,
“Name”: “Build apps in Azure DocumentDB leveraging your C# and SQL skills”,
“Description”: “Ever wanted to dip your toes into the NoSQL pool? If you’re a .NET and SQL Server developer, Azure DocumentDB makes it pretty easy for you to do so. We will build a simple ASP.NET MVC web app that uses C# and DocumentDB for CRUD operations. Then we’ll walkthrough writing queries for DocumentDB by leveraging your SQL and LINQ querying skills. Also on the agenda: SQL vs NoSQL, a look at NoSQL offerings on Azure and use cases for DocumentDB”
“Name”: “Azure IAAS: Intro to Virtual Machines and Virtual Networks”,
“Description”: “While deploying your Azure apps with app service or container may be the ‘in’ options, there are plenty of scenarios needing an Azure Virtual Machine. In this talk, we’ll talk about when to and when NOT to use VMs. We’ll create a virtual network with a Windows and a Linux VM and have them communicate with each other. Time permitting we will talk about concepts like SLA, scaling, Powershell automation and VM extensions.”
Enter the Azure DocumentDB Capacity Planner tool.
Trying to draw some estimates for a Codecamp that has between 500-1000 attendees, I use 3 scenarios:
1. Create – At peak signup time, up to 10 speakers would be submitting sessions (we get 2).
2. Read – Peak traffic of up to 100 attendees view the sessions for a particular speakers (on the higher side of peak traffic for the website).
3. Delete – At peak signup time, up to 10 speakers drop their session (we get maybe 10 drops per year).
I save my sample data as a JSON file and upload with the tool. Running these estimate plus my sample data in the Capacity Planner tool, I get an estimate RU value of 428 (see below screenshot). Given my huge padding numbers, this tells me that I can safely provision my collection for the minimum allowable 400 RUs and be guaranteed that throughput performance for my Azure DocumentDB collection at all times!
If you liked this post, please share it on social media and follow me on Twitter @_s_hari
Is there anything I’m leaving out? Feel free to share in the comments below.