Our new D-Series VMs provide great performance for applications needing fast, local (ephemeral) storage or a faster CPU; however, it’s important to understand a little about how the system is configured to ensure you’re getting an optimal experience.

The cloud is a shared environment, so most VMs share a server with one or more other VMs. To ensure that one VM doesn’t use more than its fair share of shared resources we apply limits to the number of virtual CPUs, RAM, local disk capacity, and IO throughput made available to a VM based on the VM type. These limits help ensure that all users see more consistent, predictable performance from the system.

For the new D-Series, here are the core counts and RAM assignment, as well as the capacity and performance expectations for local SSD by VM type:

IO Operations are limited by either Max IOPs or the Max Read/Write throughput (MB/s), whichever they hit first (for mixed workloads a write effectively counts double against the read limit). Small IO sizes will typically max out on IOPS before hitting bandwidth limits, while large IO sizes will typically max out on bandwidth before hitting IOPS limits.

Note that Max IOPS and maximum disk throughput limits apply only to the local SSD. OS, Data Disks, and Azure File persistent storage performance levels are described in the Azure Storage Scalability and Performance Targets document.

Applications that require low latency, but don’t push high IOPS or bandwidth may do well with one of the smaller SKUs. Applications that need low latency and high IOPS or high bandwidth should consider using the larger SKUs.

Local SSDs are implemented as dynamic VHDs, which means that initial writes to a sector on these disks will be slower as the VHD file expands. For optimal performance, pre-write files/disks before using them for an active workload.

Your performance may be less, especially if your application can’t drive a sufficiently parallel workload to take advantage of the full capacity.