Yesterday the post was about possibly using a move of servers to help ferret out things to review in your architecture (and not using it as a chance to necessarily block access that may have been lost control of).
There was a good point made in the comments –
John said “Those DTUs will kill your wallet if you don’t tune your DBs. I’m finding UDFs to be real DTU hogs lately.”
Interestingly, this is a benefit, I think, of moving to a new platform. Particularly one that costs based on utilization. You get a much clearer picture of your systems, utilization, and requirements because you’re potentially billed for it. At the very least, you have to fully understand what impacts the performance metrics for your provider. Previously, you’d see utilization metrics – CPU, disk, queues and such – but now you may have to consider other things, different things, or different at least in how they measure. The biggest difference I’ve seen that makes this so very important is that it can result in significant throttling of your systems if you hit any surprises along the way.
We’ve seen this in working with SQL Server, MySQL, etc. Specifically, we were working to move an application to hosted MySQL services. Where systems would slow a bit under load when too many connections tried to fire up under the cloud-based solutions, we’d get flat out denied access and our application was coming to a crashing, dramatic halt. While you may not see such a drastic impact, it’s important to understand both the metrics and how you influence them.
DTUs are a processing measurement mechanism that is used by Azure to size your database functionality instance. There are some sizing tools out there that you can run against your system at load and receive a recommendation on what you’ll need in terms of instance size on Azure. They’re a great sizing starting point. It’s an easy thing though to mis-estimate for spike utilization or even growth over time. And, as John said the cost to support utilization can be a big factor in your budget.
With RDS, the sizing is, in my opinion, less science. It seems this way to me only because there aren’t utilities or tools you can use to determine the size of the instance you should use. However, the sizing can be at least loosely based on the size of your on-premises or VM-based RDS instance. Azure is less of a 1:1 model with these as starting points, so it’s important to make sure you use the sizing estimation tools.
The strong benefit I have seen on both of these when moving an existing application is that you have some new metrics that can be used to show bottlenecks and “expensive” operations. Might well be UDFs, could be processes that are automated and run and re-run unnecessarily. By using the different tools and metrics, we’ve been able to detect some hot spots in the application where we needed to pay additional attention and do some tuning.
