Jan’s magic performance improvement wand is legendary among the Ignition team and among some of our customers. However, behind the magic lurks common sense combined with years of experience at performance tuning. Over on his personal blog, he’s written a post that focuses on some common database related performance optimisations for applications hosted on Azure.
Shifting an app to Windows Azure is a great way to expose database related performance issues. Quite simply, SQL Azure has some fundamental differences to a traditional “on site database”, such as limitations on DTUs (database throughput units) and the need to handle transient failures (micro outages, the types of which you wouldn’t see when dealing with a ‘traditional’ SQL Server) – these make performance measurements and optimisations a key part of any application’s migration to Azure.
As Jan puts it:
I’m mentioning Azure in this topic as I’ve been involved in migrating and/or improving performance for quite a few Azure sites. The perceived initial reaction on migration is generally that “Azure is slow!” which usually tends to be indicative of a bigger problem. The fact is that Azure works fine, but it highlights the performance bottlenecks in an application, especially when it comes to database access. An on-site local database server will most likely be a lot more forgiving than an azure DTU-plan.
Read the full post here: ASP.NET, Azure, Database, EntityFramework Performance Pointers
If you’d like to talk more about database performance issues of any type, then get in touch.