One of the first things to note about Azure virtual machines is that the storage subsystem is backed by virtual hard disks (vhds) which in turn are backed by Blob Storage. Blobs are an abstraction layer over what is essentially network based storage. Being on a network means more chances for latency and throughput to to affect performance versus traditional disk backed storage. That’s not to say that these risk can’t be mitigated and reduced to enjoy the benefits provided by Azure Storage such as scale, portability, and durability. I’m going to cover some of the concepts I feel are most important but the links provided at the end of the article will provide more concrete guidance from Microsoft. This information is written in the context of the latest versions of Windows (8/2012) and SQL Server (2012+). Some performance considerations however can also be applied more generally to virtual infrastructure.


Don’t skimp on your the sizing plan for your virtual machine. This is something that applies to both to physical and virtual infrastructure. Remember that SQL server is is a software product at the mercy of the CPU and Memory being allocated. Serving more data from memory than disk will almost always mean better performance. Microsoft’s guidance calls for a minimum of an A2/A3 sized virtual machine depending on the version of SQL Server but I often end up leaning towards a minimum of an A3/A4 when using standard storage accounts. If your working with very performance demanding applications you should really consider SSD backed premium storage accounts. Premium storage backed disks are only available with DS series virtual machines but the performance improvement can be night and day especially for heavy applications such as SharePoint.


Quick Tip: Want to turbo charge your SharePoint deployment? Place the SQL server temp-db file on SSD backed storage and watch it fly.


Storage Account

This may seem like a no-brainer but make sure your storage account and virtual machine are in the same region to keep latency at a minimum. It’s easy to miss when provisioning manually or through the management portal. Also, Geo-redundant storage has implicit performance limitations so it is recommended that you use locally redundant storage combined with a dedicated SQL backup strategy. More on backup later. When you attach data disks to a VM, with standard storage accounts, you have the option to enable caching at the Azure Host level. If you have light read workload, you can enable it, but if you have big file contents (more than few tens of GB) and/or write intensive workload, it is recommended to disable this option. The general consensus seems to be that it’s best to avoid using Azure data disk caching options (caching policy = None) unless you have a specific need or use-case.


That’s it for this post. Join me in the Part 2 as we talk about Operating System and SQL Server Optimizations