Sunday, November 12, 2017

Azure: DTUs and eDTUs




DTUs are being called as Database Throughput Units and sometimes as Database Transaction Units in MS articles. I believe now most widely accepted as Database Transaction Units. Azure database has different service tiers available from Basic tier to Premium RS tier. Each tier will have a different range of resources. DTUs refer to overall resources of an Azure database. So based on the tier we select for the Azure DB we will have the resources allotted for that DB. Eg: A basic tier will have 5 DTUs and so on.

In simple terms based on the service tier, you select while registering for Azure DB the number of DTUs will be provided to your DB. The performance of your DB depends on the number of DTUs.

DTUs is a collective measure of CPU, memory and I/O resources. In order to determine how many DTUs we need to select for our DB or how many DTUs your current DB is using you use this MS calculator. To determine in-depth details about resource consumption we can use “Query Performance Insights” in the Azure portal.

Now once you have selected a tier and your DB started utilizing all the available DTUs then the performance will start slowing down and if the workload still increases beyond the DTUs available after severe slowness then we will start seeing timeouts. When we start to see severe slowness/time-outs we can either perform performance tuning or upgrade to higher tier anytime.

eDTUs stands for elastic DTUs. Instead of allotting resources to a single DB, in eDTUs resources are allotted to a pool of DB’s. elastic pools will have many databases in them and resources are shared with each other. So that at any time there will not be resource crunch and another advantage of eDTUs is we can add/remove resources to the pool if required without any downtime. If we have multiple databases for which the workload is unpredictable then the best option would be to put all those databases in a pool so that maintaining those databases will be easier and also we can save cost as well. Instead of providing high resources to a single database which has highly volatile workloads if we put such database in a pool it save much cost.

Thanks VV!!

1 comment: