It’s been a while since we talked about IOPS. In fact the last post I wrote on the subject was Azure Disk IOPS and Virtual in IaaS back in November. Since then, I managed to get in the Premium storage preview, so today I thought it would be fun to see how many IOPS I can squeeze out of these machines.
Before diving into this. I do recommend the following MVA modules as a primer.
- Windows Azure Storage - Design and Implementation Jump Start
- Get Started with Windows Azure Today Jump Start
- Windows Azure for IT Pros Jump Start
The following is a list of important things to consider before or when using Premium Storage:
- Premium Storage is currently only available in the Microsoft Azure Preview Portal,
Premium Storage is available for limited preview in the following regions: West US, East US 2, and West Europe.
Premium Storage supports only Azure page blobs
If you want to use a Premium Storage account for your VM disks, you need to use the DS-series of VMs. You can use both Standard and Premium storage disks with DS-series of VMs. But you cannot use Premium Storage disks with non-DS-series of VMs.
According the the documentation when you provision a disk against a Premium Storage account, how much input/output operations per second (IOPS) and throughput (bandwidth) it can get depends on the size of the disk. Currently, there are three types of Premium Storage disks: P10, P20, and P30. Each one has specific limits for IOPS and throughput as specified in the following table:
I decided to test this by creating a DS14 machine with some P30 disks attached to it to see what kind of IOPS I could really get. So I created three disks to figure out if there was a real difference between a disk without Host Cache, with Read Only or Read write cache
In the last article I used SQLIO from http://www.microsoft.com/en-ca/download/details.aspx?id=20163. SQLIO is a free tool provided by Microsoft which can also be used to determine the I/O capacity of a given configuration. In order to compare apples to apples, I am using the same tool with the same read/write operation patterns.
To test, I used the following command:
SQLIO -kRW -s60 -o8 -b8 f:\testfile.dat
The -k option, which specifies the I/O type (R for read operations and W for write operations)
The -s option to specify the test duration in seconds.
The -o, which indicates the number of I/Os that can be outstanding in a single thread. In this case, I’ve specified 8, so each thread can support up to eight outstanding I/O requests. Next we come to the -b option. This is the I/O block size in kilobytes (KB). In the example, I specified 64.
The last option in the command is -F, which points to the configuration file and the parameters defined within it. When you run the command, it creates the test file on the target drive and returns details about the execution, as shown in the following results:
Here are my results:
No Host Cache
Read Only Cache
Conclusion. I really like the fact that the IOPS profile is slightly above the specs that are listed in the documentation (5101 average IOs/Sec compared to 5000 in the documentation). However, I still looking for the configuration that will give me that elusive 50000 IOs/Sec. I guess that will be for next week.