Understand Azure Files performance

Here’s a concise summary of the article "Understand and optimize Azure file share performance."

Overview

Azure Files can meet performance needs for most apps. The article describes factors that affect file share performance and how to optimize shares for specific workloads.
It also lists applicable combinations of management model, billing model, media tier, redundancy, and protocol (SMB/NFS). (Original table retained in source.)

Key terms (glossary)

IOPS: Input/output operations per second (operations/transactions).
I/O size: Size of each I/O request (e.g., 4 KiB to 1 MiB); strongly affects achievable throughput.
Throughput: Bits transferred per second (MiB/s). Throughput ≈ IOPS × I/O size.
Latency: Delay measured in ms. Two types discussed: end-to-end and service latency.
Queue depth: Number of pending I/O requests a storage resource can handle at once.

Choosing SSD vs HDD

Two media tiers: SSD (premium) and HDD (standard). The storage account’s media tier is fixed for a given account; moving tiers requires manual migration to a new share.
SSD is recommended when you need high IOPS, higher throughput, or low latency.
SSD supports guaranteed provisioning (see provisioned v1 model). SSD typically delivers single-digit ms read/write latency; HDD may not for read latency.

Performance checklist (to select/configure storage)

Latency sensitivity: If read latency is user-visible, prefer SSD (single-millisecond read/write for small I/O).
IOPS and throughput needs: SSD supports higher limits—see the storage-files scale targets link.
Workload duration/frequency: Short, infrequent workloads may not reach HDD upper limits; tests must run long enough and at realistic frequency.
Workload parallelization: Parallel workloads (multiple threads/processes/clients) perform better—SMB Multichannel benefits SSD shares.
API/metadata-heavy workloads: Metadata-heavy workloads (many file reads) are better suited to SSD.

Latency details

Two latency metrics:
- SuccessE2ELatency (end-to-end): client → network → Azure Files → client.
- SuccessServerLatency (service): only time inside Azure Files (excludes client/network).
Difference between the two indicates client or network latency.
Geographic proximity matters: farther clients see greater end-to-end latency. Testing from an Azure VM is recommended to baseline network impact (ExpressRoute/VPN sizing and routing can affect results).

Queue depth

Queue depth = clients × files × threads. High queue depth (parallelism) is desirable for Azure Files to reach higher performance; target up to ~64 (exceeding it rarely helps and may increase latency).
The article gives example combinations showing how to reach higher queue depth.
Tip: Benchmark with multi-threaded, multi-file workloads to reach upper performance limits.

Single-thread vs multi-thread applications

Azure Files benefits greatly from multi-threaded workloads.
Example: Creating a single 16 KiB file with 4 KiB writes takes ~14 ms single-threaded. Copying 10,000 files sequentially would take ~140 s. Using 8 parallel threads reduces the wall time dramatically (to ~17.5 s in the example).
Parallelizing file operations can yield major reductions in elapsed time.