Performance of Azure VM's using Standard Disk Storage

Some of our clients have been experiencing a drop in performance when they moved their applications from an on-premise server or a hosted server environment to an Azure VM running on standard storage.

Based on this article Performance Best Practices for SQL Server in Azure Virtual Machines it is recommended to “Stripe multiple Azure data disks to get increased IO throughput”. Even though my clients’ applications are not necessarily SQL server, we decided to assess the performance gains in disk I/O by striping the disks of an Azure VM.

Our choice of testbed was a Standard_A4 VM (8 Cores, 14GB memory). I kept the OSDisk as is and added a “Data Disk” with a total of 512 GB capacity. All Standard non-SSD Storage.

Here are the scenarios for our test:

  • Scenario 1 – 512 GB disk with no-caching

  • Scenario 2 – 512 GB disk with R/W caching

  • Scenario 3 – 512 GB disk striped to 2 - 256 GB disk with R/W caching

  • Scenario 4 – 512 GB disk striped to 4 - 128 GB disk with R/W caching

  • Scenario 5 – 512 GB disk striped to 8 - 64 GB disk with R/W caching

We used IOMeter to create the same load across all 5 scenarios.

Here are the results (Compare them with the Azure documented specs of 500 IOPS and 60 MB/S for Standard Storage Disks):

Keep in mind that while striping improves the performance, you are limited in two ways:

  1. Once you stripe the disk, you cannot anymore scale that disk to increase its storage without wiping it out and recreating it with all its content.

  2. You can stripe a limited number of disks, for example the Standard_A4 VM can only attach to 16 disks. This limits your number of data disks. In the case of SQL if you need to separate between log, data and tempdb disks and want to create 8-disk stripes, you cannot do that. You’ll have to go down to 4-disk stripes to have 3 data disks with a total of 12-stripes or you can do an 8-disk stripe for the data and 4-disk stripes for the log and tempdb.

Here are more details on the IOMeter results:

Scenario 1:

Scenario 2:

Scenario 3:

Scenario 4:

Scenario 5: