Tuning Windows Azure Performance, more thoughts

As a follow up to my previous blog post, Tuning Windows Azure Performance, a brief introduction I would like to share some more thoughts about tuning Windows Azure performance.

Affinity Groups

If different components of your Azure solution is deployed to different Azure data centers (DC) there’s a big chance that you will have to deal with additional network related issues.

Imagine a scenario where your web front tier is deployed in an Asia DC, web services tier in a Europe DC and database in a US DC. Doesn’t sound logical, right?

For optimal performance it would be best to deploy as many solution components as possible in the same data center.

You can check Importance of Affinity Groups in Windows Azure  for more information. (Thanks to Holger Sirtl for reminding this topic to me)

Multi tenancy of Windows Azure SQL Database (formerly known as SQL Azure)

Windows Azure SQL Database is a self managed service starting as low as $5 (as of August 2012)

In certain scenarios Azure SQL Database users can face performance issues due to the multi tenanted nature of the service.

The only way to make a SQL Database service available at a very low cost is to make sure multiple customers (tenants) share the same hardware resources together.

As of August 2012 the cost of Azure SQL DB is determined “only” by the size of the DB. The smaller the size, the less you pay. And naturally the more tenants you share the hardware with. Even if you have a 50 MB small DB that needs to process a lot of transactions, as of today there is not a way to “pay more” and “get more” hardware resources.

For these types of scenarios you can choose to install our good old SQL Server on a persistent Azure VM (aka Infrastructure as a Service or simply IaaS)

With SQL Server on IaaS we can get dedicated VMs for our DB, no matter what the size of the DB is and utilize all the hardware resources dedicated to our VM.

As you can easily guess there are some disadvantages of this approach. Firstly you have to pay more since you hold dedicated hardware resources for your DB. And also you have to manage the SQL Server yourself which will also increase the cost of maintenance.

For more information you can check SQL Server in Windows Azure Virtual Machine Early Adoption Cook Book

Note: Persistent VM feature is published on June 2012 and will probably stay as a preview service for a few more months to come. You can use it for production purposes but Microsoft will not give you SLA until the service is made generally available (GA)

Update: If you need more disk IO performance on an IaaS VM you can use multiple network attached disks to boost performance. You can do disk striping (RAID 0) and since Azure network drives are fault tolerant by default you get both better performance and reliability. Also please remember to use different storage accounts for each disk to further boost performance. Please check this 10 minute for more information, https://channel9.msdn.com/Shows/TechNet+Radio/TechNet-Radio-IT-Time--Part-5-Real-World-Azure--Provisioning-Storage-for-IO-Intensive-Applications-o

Update: For higher SQL Server disk IO performance using multiple file groups are preferred instead of disk striping. Please check http://msdn.microsoft.com/en-us/library/windowsazure/dn133149.aspx for more info.

Update: If you are designing massive scale applications you might find the following quite interesting to read
Best Practices for the Design of Large-Scale Services on Windows Azure Cloud: http://msdn.microsoft.com/en-us/library/windowsazure/jj717232.aspx
Designing and Deploying Internet-Scale Services: www.usenix.org/events/lisa07/tech/full_papers/hamilton/hamilton.pdf  (beware, it's a bit heavy in theory and not an easy read)

Comments (2)
  1. Jason Dean says:

    I've also noticed with the VM solution that you need to add a data disk to the VM to store the databases. The only disk that is persistant is the OS Disk. I also get quite a slow response when writing to the attached disk. It would be interesting if someone has done speed tests for this.

  2. Hakan Eren says:

    Hi Jason,

    You have to take one thing into consideration.. Azure storage is not expensive SAN drives where you attach to your server using expensive fiber cards. It is commodity hardware (disks and network equipment) we are talking about and I believe this is a good thing.

    There is really a trade-off, you can't use local disks due to high availability reasons. And SAN will be too expensive to make it feasible for internet scale.

    Therefore there will be some impact on the disk performance but a lot of cost savings.

    I believe you can always find alternatives to live with some performance loss on disks. Splitting DBs (using federation or other options), using alternative auto-scale DB options like Azure Tables (NoSQL) etc.

    Other than this I suggest you check the below to see if your disk performance is optimal.



Comments are closed.

Skip to main content