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 https://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: https://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)