We migrated a heavy compute workload to Azure IaaS recently, but the performance is erratic. Sometimes it flies, and other times it crawls. I am using standard SSDs and keeping an eye on CPU utilization. Could this be related to disk bursting or network bottlenecks? I am struggling to troubleshoot this because the monitoring metrics seem fine, but our end-users are complaining about lag.
Inconsistent VM performance on Standard SSDs in Azure is typically caused by storage IOPS and throughput throttling due to the variable performance nature of the disk tier, which is resolved by upgrading to Premium SSDs for guaranteed sustained performance.
7 answers
Standard SSDs are the wrong choice for a heavy compute workload, plain and simple. They use a variable performance model that fluctuates based on host contention, which makes them essentially useless for anything requiring consistent, high-speed data processing. Swap them out for Premium SSDs immediately or your users will continue to complain about lag.
Standard SSDs in Azure are notorious for performance variability because they rely on variable IOPS and throughput caps. You are almost certainly hitting your IOPS limits during peak times and getting throttled, which explains why your average metrics look fine while the latency spikes.
I recall managing a similar migration for a retail client where we spent weeks chasing ghosts in the monitoring dashboard. We eventually found that the application was queuing requests in a way that didn't trigger high CPU alarms but completely saturated the disk write buffer.
It turned out the underlying storage host was oversubscribed, and our workload was fighting for contention during batch processing windows. Moving that specific VM to Premium SSD solved the latency issue almost overnight because the disk performance became predictable and dedicated rather than burstable.
You need to drill down into the specific bottlenecks causing this erratic behavior.
- Enable Azure Monitor Metrics for Disk Read/Write Bytes to spot throttling events.
- Check if your VM size supports the disk throughput you actually require during peak load.
- Verify if network flow logs show latency between the VM and the data backend.
- Switch to Premium SSD storage to eliminate I/O variance across your compute clusters.
Standard SSDs function adequately for development environments with low-intensity disk access, but they fail to maintain consistent latency for enterprise-grade workloads where predictable performance is a compliance requirement. Transitioning to Premium SSDs provides better service level guarantees because the disk performance is not tied to the same variable bursting mechanics found in the standard tier. If your workload involves significant data throughput, the trade-off is clear: you either pay for the sustained performance of a higher storage tier or you accept the periodic performance degradation inherent in shared-infrastructure storage.
The issue stems from the fact that Standard SSD performance is not fixed; it fluctuates based on the underlying disk capacity and the current demand on the shared Azure storage cluster. When you observe erratic performance, it is likely that your application has exceeded its allotted IOPS and throughput burst limits, triggering artificial throttling by the storage controller.
Monitoring tools often aggregate data over one-minute or five-minute intervals, which frequently masks micro-bursts of high disk activity that trigger this throttling. If your compute workload is truly heavy, your disk queue depth is likely increasing significantly during these periods of high activity, causing the latency end-users perceive as lag.
There is also the possibility of a network-level bottleneck, but disk contention on Standard SSDs is the primary suspect in 90 percent of these cases. To confirm this, you should enable multi-dimensional metrics in Azure Monitor specifically for Disk Latency and check for the 'Throttled' metric status on your individual disks. If you see spikes in the throttled metric, no amount of CPU optimization will fix your problem because the bottleneck is purely at the storage layer. Moving to a disk tier with higher sustained performance limits is the standard remedy for this specific pattern of behavior.
Is your application behavior consistent or is it triggered by scheduled jobs? I once tracked an erratic system to a database index rebuild that ran every hour and exhausted the disk burst credits within minutes. Once the credits were depleted, the VM performance would throttle to the baseline rate, creating that exact crawling sensation your users are reporting.
We analyzed the metrics by exporting them to a Log Analytics workspace and saw the correlation between the disk depth and the job start times. After we moved the data files to a Premium SSD managed disk, the performance stabilized because we no longer relied on a burst bucket that was being emptied by maintenance tasks. You should audit your job schedule to see if it aligns with the lag reports.
