Performance azure disks, high average queue length
Solution 1:
You're focusing a bit much on a single metric!
Diagnosing a bottleneck to a single component rarely ends with one counter giving a full explanation.
There are quite a few great guides for using perfmon to diagnose performance problems on SQL Server.
And unfortunately your Admin could be right, the counter you choose does indeed depend on the underlying hardware. However I can't find any documentation stating that Azure is based on a 6 disk raid. So perhaps focus on other counters?
- Avg. Disk sec/Read
- Avg. Disk sec/Write
- Disk Read/sec
- Disk Writes/sec
But as a final recommendation. If your only indication was the Avg. Disk Queue Length, your Sysadmin is probably right.
If you're sure it's a disk issue, you can always try creating storage spaces.
Solution 2:
Fairly new to Azure, but here's my offering:
The more Azure disks you span the better your performance will be, this is true. I'm not sure about the equation though. Either way, I think you're barking up the wrong tree...
Azure imposes artificial limits on metrics such as IOPS and Max reads/writes per second, so the queue length is only one of a few metrics that you need to look at.
This question is similar in nature to yours. It has a helpful reference to an Azure SQL performance article, too. Ensuring you follow Microsoft's best-practise could help you to improve performance.
I'm not sure further increasing the number of disks you use will help. From what I've seen, the growth is not linear. You might expect the IOPS for 6 disks to be 3000 (6x500) but it's probably more like 2000.
Moving to the DS (SSD) tier might be the only way to get the kind of performance you are looking for from a single VM. Here is a run-down of the the Azure instance limits: https://azure.microsoft.com/en-gb/documentation/articles/virtual-machines-size-specs/
Lastly, the best way to improve perfomance of any application is to reduce the reliance on I/O. Cache wherever possible. You could try an instance with more memory.