了解和優化 Azure 檔案共用效能
Azure 檔案儲存體可以滿足大部分應用程式和使用案例的效能需求。 本文會說明可能影響檔案共用效能的不同因素，以及如何最佳化工作負載的 Azure 檔案共用效能。
適用於
| 檔案共用類型 | SMB | NFS |
|---|---|---|
| 標準檔案共用 (GPv2)、LRS/ZRS |  |
 |
| 標準檔案共用 (GPv2)、GRS/GZRS | |
|
| 進階檔案共用 (FileStorage)、LRS/ZRS | |
|
字彙
在閱讀本文之前，可先了解與儲存體效能相關的一些重要詞彙：
每秒的 I/O 作業數 (IOPS)
IOPS (每秒的輸入/輸出作業) 會測量每秒檔案系統作業的數目。 「IO」一詞可與 Azure 檔案儲存體文件中的「作業」和「交易」字詞交換使用。
I/O 大小
I/O 大小 (有時稱為區塊大小) 是應用程式用來在儲存體上執行單一輸入/輸出 (I/O) 作業的要求大小。 根據應用程式而定，I/O 大小的範圍從非常小 (例如 4 KiB) 到非常大都有可能。 I/O 大小對於達成輸送量而言至關重要。
輸送量
輸送量會測量每秒讀取或寫入儲存體的位元數，並以每秒的兆位元組數為單位測量 (MiB/秒)。 若要計算輸送量，請將 IOPS 乘以 I/O 大小。 例如，10,000 IOPS * 1 MiB I/O 大小 = 10 GiB/s，而 10,000 IOPS * 4 KiB I/O 大小 = 38 MiB/s。
延遲
延遲有一組同義字 (Latency 和 delay)，通常以毫秒為單位來測量 (ms)。 延遲有兩種類型：端對端延遲和服務延遲。 如需詳細資訊，請參閱延遲。
佇列深度
佇列深度是儲存體資源一次可處理的擱置 I/O 要求數目。 如需詳細資訊，請參閱佇列深度。
根據使用模式選擇效能層級
Azure 檔案儲存體提供一系列的儲存層，可讓您以適當的效能和價格層級儲存資料，以協助降低成本。 在最高層級，Azure 檔案儲存體提供兩種效能層級：標準和進階。 標準檔案共用裝載在硬碟 (HDD) 支援的儲存體系統上，而進階檔案共用則由固態硬碟 (SSD) 支援，以提升效能。 標準檔案共用有數個儲存層 (最佳化的交易、經常性儲存層和非經常性儲存層)，您可以順利切換，以充分運用待用儲存體的資料和交易價格。 不過，您在標準層和進階層之間切換時，必須要在不同的記憶體帳戶之間移轉資料。
在標準檔案共用與進階檔案共用之間進行選擇時，請務必了解您打算在 Azure 檔案儲存體上執行的預期使用模式需求。 如果您需要大量的 IOPS、極快的資料傳輸速度或非常低的延遲，則您應該選擇進階 Azure 檔案共用。
下表摘要說明標準與進階之間的預期效能目標。 詳細資料請參閱Azure 檔案儲存體擴充性和效能目標。
| 使用模式需求 | 標準 | 高級 |
|---|---|---|
| 寫入延遲 (單一位數毫秒) | Yes | Yes |
| 讀取延遲 (單一位數毫秒) | No | Yes |
進階檔案共用提供佈建模型，可保證以下根據共用大小的效能設定檔。 如需詳細資訊，請參閱佈建的模型。 當檔案共用的流量低於基準 IOPS 時，將會在高載貯體中累積高載額度。 稍後會使用所獲額度，在作業超過基準 IOPS 時啟用高載。
| 容量 (GiB) | 基準 IOPS | 高載 IOPS | 高載額度 | 輸送量 (輸入 + 輸出) |
|---|---|---|---|---|
| 100 | 3,100 | 最高 10,000 | 24,840,000 | 110 MiB/秒 |
| 500 | 3,500 | 最高 10,000 | 23,400,000 | 150 MiB/秒 |
| 1,024 | 4,024 | 最高 10,000 | 21,513,600 | 203 MiB/秒 |
| 5,120 | 8,120 | 最高 15,360 | 26,064,000 | 613 MiB/秒 |
| 10,240 | 13,240 | 最高 30,720 | 62,928,000 | 1,125 MiB/秒 |
| 33,792 | 36,792 | 最高 100,000 | 227,548,800 | 3,480 MiB/秒 |
| 51,200 | 54,200 | 最高 100,000 | 164,880,000 | 5,220 MiB/秒 |
| 102,400 | 100,000 | 最高 100,000 | 0 | 10,340 MiB/秒 |
效能檢查清單
無論您是評估新工作負載或現有工作負載的效能需求，了解您的使用模式將協助您達到可預測的效能。 請洽詢您的儲存體管理員或應用程式開發人員，以判斷下列使用模式。
延遲敏感度：使用者是否會開啟檔案，或與在 Azure 檔案儲存體上執行的虛擬桌面互動？ 這些是讀取延遲較為敏感的工作負載範例，終端使用者也有很高的可見度。 這些類型的工作負載更適合進階 Azure 檔案共用，可為讀取和寫入作業提供單一毫秒延遲 (<小型 I/O 大小為 2 豪秒)。
IOPS 和輸送量需求：進階檔案共用支援比標準檔案共用更大的 IOPS 和輸送量限制。 如需詳細資訊，請參閱檔案共用級別目標。
工作負載持續時間和頻率：相較於長時間執行且經常發生的工作負載，短時間執行 (幾分鐘) 和低頻率 (每小時) 的工作負載較不可能達到標準檔案共用的效能上限。 在進階檔案共用上，根據佈建大小決定要使用的合適效能設定檔時，工作負載持續時間相當實用。 根據工作負載需要高載的時間長度，以及其花費低於基準 IOPS 的時間長度而定，您可以判斷是否累積足夠的高載額度，以在尖峰時間持續滿足工作負載需求。 相較於過度佈建檔案共用，找到合適的平衡將可降低成本。 一項常見的錯誤是只執行幾分鐘的效能測試，結果通常會產生誤導。 若要取得實際的效能檢視，請務必以足夠高的頻率和持續時間進行測試。
工作負載同時處理：對於同時執行作業的工作負載 (例如透過相同用戶端上的多個執行緒、流程或應用程式執行個體)，進階檔案共用提供優於標準檔案共用的明顯優勢：SMB 多重通道。 如需詳細資訊，請參閱改善 SMB Azure 檔案共用效能。
API 作業散發：工作負載中繼資料是否繁重，包含檔案開啟/關閉作業？ 對於針對大量檔案執行讀取作業的工作負載而言，這很常見。 請參閱中繼資料或命名空間繁重的工作負載。
Latency
考慮延遲時，請務必了解 Azure 檔案儲存體如何判斷延遲。 最常見的度量是與端對端延遲和服務延遲計量相關聯的延遲。 使用這些交易計量，可藉由判斷應用程式流量在與用戶端的來回傳輸中花費多少時間，來協助識別用戶端延遲和/或網路問題。
端對端延遲 (SuccessE2ELatency) 是交易執行從用戶端、經由網路、到 Azure 檔案儲存體服務、回到用戶端的完整來回行程所花費的總時間。
服務延遲 (SuccessServerLatency) 是交易只在 Azure 檔案儲存體服務內往返所需的時間。 不包含任何用戶端或網路延遲。
SuccessE2ELatency 和 SuccessServerLatency 值之間的差異可能是由網路和/或用戶端所造成的延遲。
將用戶端延遲與服務延遲 (在此案例中為 Azure 檔案儲存體效能) 混淆很常見。 例如，如果服務延遲報告低延遲，而端對端報告要求有非常高的延遲，則建議所有時間都花在與用戶端的來回傳輸，而不是在 Azure 檔案儲存體服務中。
此外，如圖所示，離服務越遠，延遲體驗越慢，而且任何雲端服務達到效能級別限制的困難度越高。 從內部部署存取 Azure 檔案儲存體時，尤其如此。 雖然 ExpressRoute 之類的選項很適合內部部署，但仍然不符合在相同 Azure 區域中唯獨執行的應用程式效能 (計算 + 儲存)。
提示
使用 Azure 中的 VM 來測試內部部署與 Azure 之間的效能，是比較 Azure 連線網路功能的實際有效方式。 工作負載時常會因為大小不夠或路由錯誤的 ExpressRoute 線路或 VPN 閘道而變慢。
佇列深度
佇列深度是儲存體資源可服務的擱置 I/O 要求數目。 隨著儲存體系統所使用的磁碟從 HDD 主軸 (IDE、SATA、SAS) 演變為固態裝置 (SSD、NVMe)，也已演化為支援更高的佇列深度。 如果工作負載是由單一用戶端所組成，且該用戶端會與大型資料集內的單一檔案依序互動，就是低佇列深度的一個例子。 相反地，支援多個執行緒和多個檔案同時處理的工作負載可以輕鬆達到高佇列深度。 由於 Azure 檔案儲存體是一種分散式檔案服務，橫跨數千個 Azure 叢集節點，且設計用來大規模執行工作負載，因此建議您建置及測試具有高佇列深度的工作負載。
高佇列深度可以透過數種不同的方式，結合用戶端、檔案和執行緒來達成。 若要判斷工作負載的佇列深度，請將用戶端數目乘以檔案數目，再乘以執行緒數目 (用戶端 * 檔案 * 執行緒 = 佇列深度)。
下表說明可用來達到更高佇列深度的各種組合。 雖然您可以超過 64 的最佳佇列深度，但我們不建議這麼做。 如果這麼做，將不會再看到效能提升，而且因為 TCP 飽和而有增加延遲的風險。
| 用戶端 | 檔案 | 執行緒 | 佇列深度 |
|---|---|---|---|
| 1 | 1 | 1 | 1 |
| 1 | 7 | 2 | 2 |
| 1 | 2 | 2 | 4 |
| 2 | 2 | 2 | 8 |
| 2 | 2 | 4 | 16 |
| 2 | 4 | 4 | 32 |
| 1 | 8 | 8 | 64 |
| 4 | 4 | 2 | 64 |
提示
若要取得較高的效能上限，請確定您的工作負載或基準測試是多檔案搭配多執行緒。
單一與多執行緒應用程式
Azure 檔案儲存體最適合多執行緒應用程式。 若要了解多執行緒對工作負載的效能影響，最簡單的方式是逐步瀏覽 I/O 的案例。 在下列範例中，我們有一個工作負載，需要儘快將 10,000 個小型檔案複製或貼到 Azure 檔案共用。
此表格會根據以 4 KiB 區塊大小寫入的單一執行緒應用程式，細分在 Azure 檔案共用上建立單一 16 KiB 檔案所需的時間 (以毫秒為單位)。
| I/O 作業 | 建立 | 4 KiB 寫入 | 4 KiB 寫入 | 4 KiB 寫入 | 4 KiB 寫入 | 關閉 | 總數 |
|---|---|---|---|---|---|---|---|
| 執行緒 1 | 3 毫秒 | 2 毫秒 | 2 毫秒 | 2 毫秒 | 2 毫秒 | 3 毫秒 | 14 毫秒 |
在此範例中，大約需要 14 毫秒的時間，才能從六項作業建立單一 16 KiB 檔案。 如果單一執行緒應用程式想要將 10,000 個檔案移至 Azure 檔案共用，則會轉譯為 140,000 毫秒 (14 毫秒 * 10,000) 或 140 秒，因為每一次會依序移動一個檔案。 請記住，服務每個要求的時間主要取決於計算和儲存彼此的距離，如上一節所述。
使用八個執行緒而非一個，可以將上述工作負載從 140,000 毫秒 (140 秒) 縮減為 17,500 毫秒 (17.5 秒)。 如下表所示，當您以同時的方式移動八個檔案，而不是一次移動一個檔案時，您移動相同數量的資料時可以減少 87.5% 的時間。
| I/O 作業 | 建立 | 4 KiB 寫入 | 4 KiB 寫入 | 4 KiB 寫入 | 4 KiB 寫入 | 關閉 | 總數 |
|---|---|---|---|---|---|---|---|
| 執行緒 1 | 3 毫秒 | 2 毫秒 | 2 毫秒 | 2 毫秒 | 2 毫秒 | 3 毫秒 | 14 毫秒 |
| 執行緒 2 | 3 毫秒 | 2 毫秒 | 2 毫秒 | 2 毫秒 | 2 毫秒 | 3 毫秒 | 14 毫秒 |
| 執行緒 3 | 3 毫秒 | 2 毫秒 | 2 毫秒 | 2 毫秒 | 2 毫秒 | 3 毫秒 | 14 毫秒 |
| 執行緒 4 | 3 毫秒 | 2 毫秒 | 2 毫秒 | 2 毫秒 | 2 毫秒 | 3 毫秒 | 14 毫秒 |
| 執行緒 5 | 3 毫秒 | 2 毫秒 | 2 毫秒 | 2 毫秒 | 2 毫秒 | 3 毫秒 | 14 毫秒 |
| 執行緒 6 | 3 毫秒 | 2 毫秒 | 2 毫秒 | 2 毫秒 | 2 毫秒 | 3 毫秒 | 14 毫秒 |
| 執行緒 7 | 3 毫秒 | 2 毫秒 | 2 毫秒 | 2 毫秒 | 2 毫秒 | 3 毫秒 | 14 毫秒 |
| 執行緒 8 | 3 毫秒 | 2 毫秒 | 2 毫秒 | 2 毫秒 | 2 毫秒 | 3 毫秒 | 14 毫秒 |