If you've done any work in the Azure SQL Database, you know that the pricing model is very strange. Each service tier of database you choose is based on DTUs, or Database Transaction Units. Microsoft guarantees a certain level of DTUs for a given service level, which is somewhat funny since the DTU is defined as a transaction per second (roughly). This is a relative level of performance, but it is based on a full loaded system in the real world. However a transaction isn't a transaction.
In other words, we have no idea what a DTU is, much less the more confusing eDTUs used in Elastic databases. Since a 100 DTU database, an S3, will cost you US$150/month, it would be nice to better understand how your workload might map to the DTUs. There is the Azure SQL Database DTU Calculator to help, but's still a bit fuzzy as to how this works.
However, with extensive research, some undocumented Hyper-V commands to gain insight about the hardware underlying a particular machine, as well as some information coaxed from less scrupulous Azure data center employees, there is a site that has detailed information on how a DTU is calculated in the Azure SQL Database.
What's interesting is the formula is essential a well known math equation. The expression used is:
where know that the DTU is equal to the change in psi (
) over the change in time. Essentially the DTU is a rate of work, and you pay for a certain number of these. The rest of the formula is decoded as follows:
- h = CPU percentage for the sqlservr.exe process only
- m = cores / CPU, from the Hyper-V view
- x = memory in 10GB increments
- V = IOPS/sec, based on 10Gbs flow across a storage mesh
The rest of the formula doesn't really matter because this is an April Fools joke. We have no idea what the actual formula is, nor do I suspect Microsoft will do more than map this to transactions. Some real thoughts in the next few weeks on what DTUs might mean for us at some point.