When storage operations are slow, the assumption is that the storage tier is the problem. Upgrade to Premium, get faster throughput, move on. Except sometimes the bottleneck is not where you think it is, and a £780/month tier change will not fix a network issue.
We see this pattern regularly: an analytics environment running ADLS Gen2 on Premium tier, holding a couple of terabytes of data, with merge operations taking far longer than they should. The instinct is to blame the storage tier. The better move is to check the data first.
Checking What Azure Actually Tells You
Azure Storage exposes three latency metrics that most people do not realise are separate measurements.
End-to-end latency. The total time from when Azure Storage receives the request to when it sends the last byte of the response. This includes network transit, server processing, and the response journey back.
Server latency. The time Azure Storage spends processing the request on its side. This is the storage tier performance.
The difference between end-to-end and server latency is the network and client overhead. This is the number that tells you whether your problem is storage or network.
You can pull these from the portal:
- Go to your storage account, then Monitoring, then Metrics.
- Add metric: Success E2E Latency (end-to-end).
- Add metric: Success Server Latency.
- Set the time range to cover your slow operation window.
- Use Avg for a baseline view and P99 for worst-case.
The Numbers That Changed Everything
For a slow set of merge operations, a typical reading looks like this:
| Metric | Average | P99 |
|---|---|---|
| End-to-end latency | 45ms | 380ms |
| Server latency | 8ms | 35ms |
| Network/client overhead | 37ms | 345ms |
The server was processing requests in 8 milliseconds on average. Even at the 99th percentile, only 35 milliseconds. The vast majority of the latency (over 80%) was in the network and client components.
Premium tier would have reduced the server latency from 8ms to perhaps 2-3ms. It would have done nothing about the 37ms of network overhead.
The Move to Standard
When the data shows disk performance is not the constraint, moving from Premium to Standard is straightforward (though it means creating new storage accounts, since you cannot change account_kind in place, and migrating the data across). The metrics justify the effort.
A handful of storage accounts on Premium can run several hundred pounds a month. On Standard, a fraction of that, often the better part of £9,000 a year for a modest estate. And because the bottleneck was the network rather than the disk, the merge operations show similar performance on Standard: server latency rises slightly (from 8ms to around 12ms average) but that is invisible next to the network overhead.
Before You Upgrade Storage Tiers
Before committing to any storage tier change on Azure, pull the end-to-end and server latency metrics first. The gap between them tells you immediately whether your storage tier or your network path is the constraint.
If server latency is consistently high (above 50ms average for Standard, above 10ms for Premium), a tier change may genuinely help. If the gap between end-to-end and server latency is the dominant component, your money is better spent on network optimisation, client configuration, or architectural changes.
Storage performance problems are not always storage problems. Azure gives you the metrics to prove it.
Is your Azure storage bill growing but performance still lagging? Our free assessment includes a storage tier analysis with the actual metrics, not assumptions.