You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: articles/storage/files/understand-performance.md
+33-38Lines changed: 33 additions & 38 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -1,6 +1,6 @@
1
1
---
2
2
title: Understand Azure Files performance
3
-
description: Learn about the factors that can impact Azure file share performance such as IOPS, throughput, latency, and queue depth, and how to optimize performance for your workload.
3
+
description: Learn about the factors that can impact Azure file share performance such as IOPS, throughput, latency, and queue depth.
4
4
author: khdownie
5
5
ms.service: azure-file-storage
6
6
ms.topic: conceptual
@@ -13,12 +13,18 @@ ms.author: kendownie
13
13
Azure Files can satisfy performance requirements for most applications and use cases. This article explains the different factors that can affect file share performance and how to optimize the performance of Azure file shares for your workload.
14
14
15
15
## Applies to
16
-
17
-
| File share type | SMB | NFS |
18
-
|-|:-:|:-:|
19
-
| Standard file shares (GPv2), LRS/ZRS |||
20
-
| Standard file shares (GPv2), GRS/GZRS |||
@@ -30,78 +36,67 @@ Before reading this article, it's helpful to understand some key terms relating
30
36
31
37
-**I/O size**
32
38
33
-
I/O size, sometimes referred to as block size, is the size of the request that an application uses to perform a single input/output (I/O) operation on storage. Depending on the application, I/O size can range from very small sizes such as 4 KiB to much larger sizes. I/O size plays a major role in achievable throughput.
39
+
I/O size, sometimes referred to as block size, is the size of the request that an application uses to perform a single input/output (I/O) operation on storage. Depending on the application, I/O size can range from small sizes such as 4 KiB to larger sizes. I/O size plays a major role in achievable throughput.
34
40
35
41
-**Throughput**
36
42
37
43
Throughput measures the number of bits read from or written to the storage per second, and is measured in mebibytes per second (MiB/s). To calculate throughput, multiply IOPS by I/O size. For example, 10,000 IOPS * 1 MiB I/O size = 10 GiB/s, while 10,000 IOPS * 4 KiB I/O size = 38 MiB/s.
38
44
39
45
-**Latency**
40
46
41
-
Latency is a synonym for delay and is usually measured in milliseconds (ms). There are two types of latency: end-to-end latency and service latency. For more information, see [Latency](#latency).
47
+
Latency is a synonym for delay and is measured in milliseconds (ms). There are two types of latency: end-to-end latency and service latency. For more information, see [Latency](#latency).
42
48
43
49
-**Queue depth**
44
50
45
51
Queue depth is the number of pending I/O requests that a storage resource can handle at any one time. For more information, see [Queue depth](#queue-depth).
46
52
47
-
## Choosing a performance tier based on usage patterns
48
-
49
-
Azure Files provides a range of storage tiers that help reduce costs by allowing you to store data at the appropriate level of performance and price. At the highest level, Azure Files offers two performance tiers: standard and premium. Standard file shares are hosted on a storage system backed by hard disk drives (HDD), while premium file shares are backed by solid-state drives (SSD) for better performance. Standard file shares have several storage tiers (transaction optimized, hot, and cool) that you can seamlessly move between to maximize the data at-rest storage and transaction prices. However, you can't move between standard and premium tiers without physically migrating your data between different [storage accounts](../common/storage-account-overview.md#types-of-storage-accounts).
53
+
## Choosing a media tier based on usage patterns
50
54
51
-
When choosing between standard and premium file shares, it's important to understand the requirements of the expected usage pattern you're planning to run on Azure Files. If you require large amounts of IOPS, extremely fast data transfer speeds, or very low latency, then you should choose premium Azure file shares.
55
+
Azure Files provides a two storage media tiers allow you to balance performance and price: SSD and HDD. You pick the media tier of the file share at the storage account level, and once you create a storage account in a particular media tier you can't move to the other one without [manually migrating to a new file share](./migrate-files-between-shares.md).
52
56
53
-
The following table summarizes the expected performance targets between standard and premium. For details, see [Azure Files scalability and performance targets](storage-files-scale-targets.md).
57
+
When choosing between SSD and HDD file shares, it's important to understand the requirements of the expected usage pattern you're planning to run on Azure Files. If you require large amounts of IOPS, fast data transfer speeds, or low latency, then you should choose SSD file shares.
| Read latency (single-digit milliseconds) | No | Yes |
59
+
The following table summarizes the expected performance targets between SSD and HDD file shares. For details, see [Azure Files scalability and performance targets](storage-files-scale-targets.md).
59
60
60
-
Premium file shares offer a provisioning model that guarantees the following performance profile based on share size. For more information, see the [provisioned v1 model](understanding-billing.md#provisioned-v1-model). Burst credits accumulate in a burst bucket whenever traffic for your file share is below baseline IOPS. Earned credits are used later to enable bursting when operations would exceed the baseline IOPS.
| 100 | 3,100 | Up to 10,000 | 24,840,000 | 110 MiB/s |
65
-
| 500 | 3,500 | Up to 10,000 | 23,400,000 | 150 MiB/s |
66
-
| 1,024 | 4,024 | Up to 10,000 | 21,513,600 | 203 MiB/s |
67
-
| 5,120 | 8,120 | Up to 15,360 | 26,064,000 | 613 MiB/s |
68
-
| 10,240 | 13,240 | Up to 30,720 | 62,928,000 | 1,125 MiB/s |
69
-
| 33,792 | 36,792 | Up to 100,000 | 227,548,800 | 3,480 MiB/s |
70
-
| 51,200 | 54,200 | Up to 100,000 | 164,880,000 | 5,220 MiB/s |
71
-
| 102,400 | 100,000 | Up to 100,000 | 0 | 10,340 MiB/s |
66
+
SSD file shares offer a provisioning model that guarantees the following performance profile based on share size. For more information, see the [provisioned v1 model](understanding-billing.md#provisioned-v1-model).
72
67
73
68
### Performance checklist
74
69
75
-
Whether you're assessing performance requirements for a new or existing workload, understanding your usage patterns will help you achieve predictable performance. Consult with your storage admin or application developer to determine the following usage patterns.
70
+
Whether you're assessing performance requirements for a new or existing workload, understanding your usage patterns helps you achieve predictable performance.
76
71
77
-
-**Latency sensitivity:**Are users opening files or interacting with virtual desktops that run on Azure Files? These are examples of workloads that are sensitive to read latency and also have high visibility to end users. These types of workloads are more suitable for premium Azure file shares, which can provide single-millisecond latency for both read and write operations (< 2 ms for small I/O size).
72
+
-**Latency sensitivity:**Workloads that are sensitive to read latency and have high visibility to end usersare more suitable for SSD file shares, which can provide single-millisecond latency for both read and write operations (< 2 ms for small I/O size).
78
73
79
-
-**IOPS and throughput requirements:**Premium file shares support larger IOPS and throughput limits than standard file shares. See [file share scale targets](./storage-files-scale-targets.md#azure-file-share-scale-targets) for more information.
74
+
-**IOPS and throughput requirements:**SSD file shares support larger IOPS and throughput limits than HDD file shares. See [file share scale targets](./storage-files-scale-targets.md#azure-file-share-scale-targets) for more information.
80
75
81
-
-**Workload duration and frequency:** Short (minutes) and infrequent (hourly) workloads will be less likely to achieve the upper performance limits of standard file shares compared to long-running, frequently occurring workloads. On premium file shares, workload duration is helpful when determining the correct performance profile to use based on the provisioning size. Depending on how long the workload needs to [burst](understanding-billing.md#provisioned-v1-bursting) for and how long it spends below the baseline IOPS, you can determine if you're accumulating enough bursting credits to consistently satisfy your workload at peak times. Finding the right balance will reduce costs compared to over-provisioning the file share. A common mistake is to run performance tests for only a few minutes, which is often misleading. To get a realistic view of performance, be sure to test at a sufficiently high frequency and duration.
76
+
-**Workload duration and frequency:** Short (minutes) and infrequent (hourly) workloads are less likely to achieve the upper performance limits of HDD file shares compared to long-running, frequently occurring workloads. On SSD file shares, workload duration is helpful when determining the correct performance profile to use based on the provisioned storage, IOPS, and throughput. A common mistake is to run performance tests for only a few minutes, which is often misleading. To get a realistic view of performance, be sure to test at a sufficiently high frequency and duration.
82
77
83
-
-**Workload parallelization:** For workloads that perform operations in parallel, such as through multiple threads, processes, or application instances on the same client, premium file shares provide a clear advantage over standard file shares: SMB Multichannel. See [Improve SMB Azure file share performance](smb-performance.md) for more information.
78
+
-**Workload parallelization:** For workloads that perform operations in parallel, such as through multiple threads, processes, or application instances on the same client, SSD file shares provide a clear advantage over HDD file shares: SMB Multichannel. See [Improve SMB Azure file share performance](smb-performance.md) for more information.
84
79
85
-
-**API operation distribution**: Is the workload metadata heavy with file open/close operations? This is common for workloads that are performing read operations against a large number of files. See [Metadata or namespace heavy workload](/troubleshoot/azure/azure-storage/files-troubleshoot-performance?toc=/azure/storage/files/toc.json#cause-2-metadata-or-namespace-heavy-workload).
80
+
-**API operation distribution**: Metadata heavy workloads, such as workloads that are performing read operations against a large number of files, are a better fit for SSD file shares. See [Metadata or namespace heavy workload](/troubleshoot/azure/azure-storage/files-troubleshoot-performance?toc=/azure/storage/files/toc.json#cause-2-metadata-or-namespace-heavy-workload).
86
81
87
82
## Latency
88
83
89
84
When thinking about latency, it's important to first understand how latency is determined with Azure Files. The most common measurements are the latency associated with **end-to-end latency** and **service latency** metrics. Using these [transaction metrics](storage-files-monitoring-reference.md#metrics) can help identify client-side latency and/or networking issues by determining how much time your application traffic spends in transit to and from the client.
90
85
91
86
-**End-to-end latency (SuccessE2ELatency)** is the total time it takes for a transaction to perform a complete round trip from the client, across the network, to the Azure Files service, and back to the client.
92
87
93
-
-**Service Latency (SuccessServerLatency)** is the time it takes for a transaction to round-trip only within the Azure Files service. This doesn't include any client or network latency.
88
+
-**Service Latency (SuccessServerLatency)** is the time it takes for a transaction to round-trip only within Azure Files. This doesn't include any client or network latency.
94
89
95
90
:::image type="content" source="media/understand-performance/storage-latency-diagram.png" alt-text="Diagram comparing client latency and service latency for Azure Files.":::
96
91
97
92
The difference between **SuccessE2ELatency** and **SuccessServerLatency** values is the latency likely caused by the network and/or the client.
98
93
99
94
It's common to confuse client latency with service latency (in this case, Azure Files performance). For example, if the service latency is reporting low latency and the end-to-end is reporting [very high latency for requests](/troubleshoot/azure/azure-storage/files-troubleshoot-performance?toc=/azure/storage/files/toc.json#very-high-latency-for-requests), that suggests that all the time is spent in transit to and from the client, and not in the Azure Files service.
100
95
101
-
Furthermore, as the diagram illustrates, the farther you are away from the service, the slower the latency experience will be, and the more difficult it will be to achieve performance scale limits with any cloud service. This is especially true when accessing Azure Files from on premises. While options like ExpressRoute are ideal for on-premises, they still don't match the performance of an application (compute + storage) that's running exclusively in the same Azure region.
96
+
Furthermore, as the diagram illustrates, the farther you're away from the service, the slower the latency experience is, and the more difficult it's to achieve performance scale limits with any cloud service. This is especially true when accessing Azure Files from on premises. While options like ExpressRoute are ideal for on-premises, they still don't match the performance of an application (compute + storage) that's running exclusively in the same Azure region.
102
97
103
98
> [!TIP]
104
-
> Using a VM in Azure to test performance between on-premises and Azure is an effective and practical way to baseline the networking capabilities of the connection to Azure. Often a workload can be slowed down by an undersized or incorrectly routed ExpressRoute circuit or VPN gateway.
99
+
> Using a VM in Azure to test performance between on-premises and Azure is an effective and practical way to baseline the networking capabilities of the connection to Azure. Undersized or incorrectly routed ExpressRoute circuits or VPN gateways can significantly slow down workloads running on Azure Files.
0 commit comments