Joey on SQL Server
Microsoft Boosts Azure Disk Efficiency With 'Performance Plus' Tier
A recent update to Azure Managed Disks offers improved storage throughput and IOPS, but testing shows Premium V2 still leads in consistency under heavy load.
- By Joey D'Antoni
- 04/22/2025
Suppose you are a technology professional dealing with data-intensive workloads. In that case, storage performance is always on your mind. Even more so in the public cloud, where storage typically has lower performance limits than the best on-premises arrays from vendors like Pure Storage and NetApp.
With that in mind, I wanted to highlight some new storage performance features Microsoft recently made generally available (GA), and walk you through my methodology for benchmarking storage. While this post will focus on Azure, you can use the techniques and scripts mentioned to test on any cloud or within your data center.
Last week, Microsoft announced the general availability of a new feature for the premium (v1) tier of Azure Managed Disks called Performance Plus. The new feature provides more bandwidth and I/O operations per second (IOPs) for disks larger than one terabyte. One of the nice benefits is that for very large data sets, you can build your storage pools with P40 or 2 TB disks because they are exactly double the performance of the P30/ 1 TB that was my former recommendation.
While Premium Plus is a free upgrade, there are a couple of caveats -- the largest being that you need to create new disks to enable it. You can use a snapshot for the basis of those new disks, but at least for database workloads, this will likely require an outage, or additional VMs to minimize the downtime for the storage move. The other caveats are that once enabled, you cannot turn off Performance Plus. And a bigger concern is that Performance Plus Disk is not eligible for Azure Site Recovery (ASR). This Azure Site Recovery limitation also applies to Managed Disk V2 and Ultra Disk, making me think there’s an upper threshold for the rate of change that ASR can handle.
To better understand the performance characteristics of this storage class, I wanted to run some benchmarking tests. When testing storage performance, I always lean towards a synthetic IO tool, like Microsoft’s DiskSpd or FIO on Linux, which performs raw I/O. When I want to measure overall throughput, I will typically use HammerDB, which can simulate a warehouse, OLTP, or blended workload through the RDBMS of your choice (SQL Server is always mine) -- this is a better approach for comparing differing classes of VMs, for example. However, in this case, since I wanted to measure the performance of two different storage classes, I only wanted to use synthetic IO.
My MVP colleague, Glenn Berry, wrote a post that I always start with when performing a DiskSpd test. I will typically adjust a couple of things -- adjusting duration, thread count (usually increasing to match CPU count on VMs), and increasing the workload file to 200 GB. The last step is probably unnecessary on cloud storage, but I got burned using a small worker file (all the IO happened in memory on my SAN), so I constantly modify that value. Glenn’s code specifies a write workload of 25 percent (and therefore a read workload of 75 percent), which, in my experience, is fairly representative of even write-intensive OLTP workloads.
Understanding Cloud Storage Performance
Storage performance in the cloud, isn’t just about the underlying disks. The class of VM you choose has a significant influence on your performance. One of the performance characteristics of each VM is the number of IOPs and the amount of storage bandwidth available to the VM. For this case, I chose the EDBSv5-16 VM, which supports 70000 IOPs and 1800 MB per second for premium storage, and 88,400 IOPS and 2300 MB per second for Premium V2 and Ultra Disks.
An important thing to understand in cloud workloads is that throttling is ever-present. It doesn't matter what service (or cloud) you are using. Still, the service will increase latency as the workload approaches its limit to protect other workloads in the environment. In VM storage this can happen at either the VM or storage layer. Typically, in a production workload, you should closely align the IOPs and bandwidth on your disks to the available IOPs and bandwidth of the VM. There are some use cases (where different databases spread across disks are busy at inherently differing times) where you may allocate disks with more IOPs than the VM to help maximize those databases. However, once again, you want to minimize noise when comparing raw disk performance, so in this case, I stayed well under my VM's IOPs limits. For this test, I stayed way under my VMs IO limits, to avoid throttling at the VM layer.
[Click on image for larger view.] Figure 1. Disc configuration for comparison.
Another part of throttling that we observe in storage is that performance can dramatically degrade as your workload approaches those limits. Throttling has been a performance concern, especially with Premium SSD v1, and was mitigated significantly by both Premium SSD v2 and Ultra Disk (which share a common hardware platform). Ultra Disk has the best profile here, but it does not justify the nearly 4-5x cost increase in most cases. So, for this test, we have two premium disks with performance plus and V2 disks -- both configured to have a total of 16,000 IOPs and 600 MB per second of bandwidth.
I wrapped DiskSpd in PowerShell to run it in a loop and added a timestamp and numerical identifier to my output file names. I also changed some of my parameters, namely thread count and duration, just to see if there was any impact on the results.
| Percentile |
Read_Avg_ms |
Write_Avg_ms |
Total_Avg_ms |
| min |
0.179 |
0.192 |
0.168 |
| 25th |
4.32 |
4.336 |
4.323 |
| 50th |
4.513 |
4.529 |
4.517 |
| 75th |
4.804 |
4.827 |
4.811 |
| 90th |
4.904 |
4.915 |
4.907 |
| 95th |
4.941 |
4.951 |
4.944 |
| 99th |
5.066 |
5.081 |
5.07 |
| 3-nines |
18.033 |
18.628 |
18.084 |
| 4-nines |
44.449 |
67.542 |
45.404 |
| 5-nines |
61.439 |
147.535 |
108.138 |
| 6-nines |
65.225 |
161.79 |
161.792 |
| 7-nines |
65.225 |
161.79 |
161.792 |
| 8-nines |
65.225 |
161.79 |
161.792 |
| 9-nines |
65.225 |
161.79 |
161.792 |
| Max |
65.225 |
161.79 |
161.792 |
Table 1. Azure Premium V2 Latency Distribution
|
| Percentile |
Read_Avg_ms |
Write_Avg_ms |
Total_Avg_ms |
| min |
0.971 |
1.049 |
0.969 |
| 25th |
1.457 |
1.38 |
1.434 |
| 50th |
1.623 |
1.518 |
1.6 |
| 75th |
1.941 |
1.852 |
1.927 |
| 90th |
14.067 |
14.169 |
14.091 |
| 95th |
23.563 |
23.772 |
23.622 |
| 99th |
36.386 |
36.275 |
36.358 |
| 3-nines |
43.552 |
43.507 |
43.536 |
| 4-nines |
49.108 |
54.611 |
50.572 |
| 5-nines |
66.313 |
67.43 |
72.648 |
| 6-nines |
74.43 |
70.966 |
82.939 |
| 7-nines |
74.43 |
70.966 |
82.939 |
| 8-nines |
74.43 |
70.966 |
82.939 |
| 9-nines |
74.43 |
70.966 |
82.939 |
| Max |
74.43 |
70.966 |
82.939 |
Table 2. Azure Premium Performance Plus Latency Distribution
|
These tables summarize data from all 15 of my test runs against each storage type. I used this script to aggregate it into a single report. We are looking for "right-tail latency," which in layman's terms means "how bad it gets when throttling kicks in". I avoid looking at the absolute latency numbers. I want to see where throttling kicks in -- where we see a significant increase in latency. With Premium V2, we don't see that increase until the 99.9th percentile of IOs.
In contrast, with Premium Performance Plus, we can see throttling kicking in at somewhere between the 75th and 90th percentile. While clearly, V2 is better overall, the latency shift for Premium Plus has been reduced compared to past testing I have done against Azure Premium disks. I recommend using V2 storage; in most cases, you can avoid using pooled disks, which reduces complexity; V2 is cheaper and gives you more dynamic control over performance. However, V2 storage still isn't available in every Azure region. If your Azure region does not have V2 storage, consider Performance Plus to turbocharge your storage performance.
Cloud storage can represent a large percentage of your cloud costs and drive your overall system performance. Like any cloud service, storage changes over time, so it's important to understand how to benchmark storage to understand the performance differences across various tiers.