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 – 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,500MiB/s pure sequential writes and ~4,400MiB/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].

SMB 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 ~120,000 pure random writes and ~470,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].