Azure NetApp Files Benchmarks

Home Directory Workload –
Optimizing Performance

With Azure NetApp Files and multiple DS14v2 Azure Virtual Machines, the overload point occurred just past 14,000+ concurrent users. FSCT workload is metadata, rather than bandwidth, intensive, consuming just about 275MiB/s of bandwidth at the ~14,000 user load point while generating roughly 23,000 input/output operations, made up of ~17,000 metadata operations and ~6,000 read/write operations.

Though capacity needs in an actual home directory environment vary, the 80MiB of space needed per FSCT user required just over 1TiB of space. In terms of bandwidth, there are two periods to consider for the ANF home directory volume: peak and non-peak usage.

During the peak-usage window, provision 5TiB of capacity to both the Premium Capacity Pool and ANF Volume. At 5TiB of allocated capacity, the ANF volume provides 320MiB/s of bandwidth. Because an ANF Capacity Pool is granular to the terabyte, and the minimum Capacity Pool size is 4TiB, reduce the capacity of both pool and volume to 4TiB during non-peak-usage to reduce costs.

Linux Workload – Throughput

The first graph represents a 64 kibibyte (KiB) sequential workload and a 1TiB working set. The graph shows that a single Azure NetApp Files volume is capable of handling between ~1,600MiB/s pure sequential writes and ~4,500MiB/s pure sequential reads.

Decrementing 10% at a time, from pure read to pure write, this graph shows what can be anticipated using varying read/write ratios [100%:0%, 90%:10%, 80%:20%, and so on].

Linux Workload – IOPS

The first graph represents a 4 kibibyte (KiB) random workload and a 1TiB working set. The graph shows that a single Azure NetApp Files volume is capable of handling between ~130,000 pure random writes and ~460,000 pure random reads.

Decrementing 10% at a time, from pure read to pure write, this graph shows what can be anticipated using varying read/write ratios [100%:0%, 90%:10%, 80%:20%, and so on].

Linux – Read Throughput

Sequential Read: ~3,500MiB/s of reads with nconnect, roughly 2.3X non-nconnect.

Linux – Write Throughput

Sequential Write: nconnect introduced no noticeable benefit for sequential writes, 1,500MiB/s is roughly both the sequential write volume upper limit as well as D32s_v3 instance egress limit.

Linux – Read IOPS

Random Read: ~200,000 read IOPS with nconnect, roughly 3X non-nconnect.

Linux – Write IOPS

Random Write: ~135,000 write IOPS with nconnect, roughly 3X non-nconnect.

SMB Multichannel (Scale Up)
Workload – IOPS

Random I/O: With the introduction of SMB Multichannel on Azure NetApp Files, note the remarkable increase in I/O and throughput for single instance workloads (200% for I/O and up to 350% for throughput). Read the FAQ for full SMB Multichannel performance information.

SMB and NFS file share aren’t affected by storage I/O limits imposed on VMs by Azure. During testing, we saw random read IOPS of up to 100,000 on a single instance, with write IOPS of up to 82,500 on a single instance, indicating an approximately 200% increase with ANF’s new SMB Multichannel capabilities.

SMB Multichannel (Scale Up)
Workload – Throughput

Sequential I/O: With the introduction of SMB Multichannel, we were able to achieve a 350% increase in sequential reads and writes using fio and a single virtual machine, with read throughput of up to 2,936MiB/s and write throughput of up to 885MiB/s.

EDA Workloads on Azure NetApp 
Files – Latency and OP Rate

The graph to the right demonstrates the I/O and latency curves typical of chip design functional testing. The test harness was driven against three separate configurations: one volume, six volumes and 12 volumes. For more information on testing methodology and reasoning, please see read EDA workloads on Azure NetApp Files.

EDA Workloads on Azure NetApp 
Files – Latency and Throughput

The graph to the left exposes the throughput garnered by the sequential workload phases (physical phases) of the EDA test harness. Notice that, from one to six volumes, the workload scaled linearly. Further, while 12 volumes provided little additional bandwidth, the 12-volume configuration did reduce overall latency at the edge. For more information on testing methodology and reasoning please see read EDA workloads on Azure NetApp Files.