Basic Azure SQL Performance

In order to consolidate some websites onto one platform I had plans to move my outdoor sites to Azure. None of my sites are particularly large in terms of load so I figured a B1 app instance and a Basic Azure SQL database would more than suffice. I spent quite some time getting my database on another provider all spruced up to make migrating to Azure easier and I moved everything over for testing not long ago. It did not go well.

I was hopeful for a slight improvement in performance by moving to Azure. My other hosting provider has some older machines and they haven’t always kept up with the latest versions of ASP.Net. With Azure I was going to keep up with the latest stuff and improve performance. Instead, performance got much worse. A main page which took 2.7 seconds to load was taking about 5 seconds on Azure.

Using the very handy WebPageTest site I came across something very interesting. When comparing the new and old sites all of the significant variance was in “first byte” time. This represents the time it takes for an HTTP request to end up with resulting output starting to appear at the client. A lot of the work to do this is database access so I tried tweaking things to see how much the database might be playing a role here.

First Byte
This Azure run was better than others, but still far slower for first byte than the old web provider (361 ms). Overall load time was 4.404 seconds. Way too much.

The first wild comparison test was one in which I pointed the Azure website back to my old hosted SQL Server instance. Realize that this database is not in the same data center as the app server. All database access would be spanning Texas. Despite this, the Azure website hitting the remote database loaded in just about 2.7 seconds. This is the same time recorded when all components were operating in their own data center. Azure Apps were not the problem. It was the database!

How Much For Performance?

One of the great things with Azure is the ability to scale objects as needed. This includes the throughput of a database. The Basic Azure SQL database is rated at 5 DTUs, a rather vague all encompassing label that doesn’t scream out performance. I’d be willing to bump up the scale of my database a bit if the results would be worth it. But how much would be required to mimic the performance I now had?

Azure SQL Performance

Leaving everything else the same I proceeded to bump up the scale of the Azure SQL database to see how many DTUs would be required to improve performance. Here are the results:

TestFirst Byte In Seconds
Current Provider.361
Remote DB.366
B 5 DTUs2.7
S0 10 DTUs1.7
S1 20 DTUs.998
S2 50 DTUs.347

Finally, I found performance that beat using the old remote database! The problem with this “solution” is the fact that the S2 database providing 50 DTUs of performance costs $75 a month. With the price of the app plan that will add up to about $120, quite a bit more than the $20 or so of the other host.

I’m willing to pay more for Azure but I’m not sure if I’m willing to pay 6 times more. Some might argue that the Azure SQL offering is more consistent with its capacity. The SQL Server on the other hosting provider may provide highly variable performance that might sometimes fall below the worst case scenario of Basic Azure SQL. I can’t deny that, but I also cannot accept pages that take twice as long to load and costs 6 times as much.

Does this mean the dream is over? Maybe not. Perhaps there’s some setting I’m overlooking. If anyone has a hint to offer I’m all ears! Until then, I’ll keep the majority of my sites where they currently reside and consider scaling back what I do have on Azure.

This entry was posted in Programming and tagged . Bookmark the permalink.

2 Responses to Basic Azure SQL Performance

  1. Steve Buttock says:

    I disagree

Leave a Reply

Your email address will not be published. Required fields are marked *