Azure 檔案儲存體可以滿足大部分應用程式和使用案例的效能需求。 本文會說明可能影響檔案共用效能的不同因素，以及如何最佳化工作負載的 Azure 檔案共用效能。
適用於
| 管理模型 | 計費模型 | 媒體層級 | 冗餘 | SMB | NFS |
|---|---|---|---|---|---|
| Microsoft 儲存服務 | 已佈建的 v2 | SSD （進階版） | 本地 (LRS) |
|
|
| Microsoft 儲存服務 | 已佈建的 v2 | SSD （進階版） | 區域 (ZRS) |
|
|
| Microsoft 儲存服務 | 已佈建的 v2 | HDD （標準） | 本地 (LRS) |
|
|
| Microsoft 儲存服務 | 已佈建的 v2 | HDD （標準） | 區域 (ZRS) |
|
|
| Microsoft 儲存服務 | 已佈建的 v2 | HDD （標準） | 異地 (GRS) |
|
|
| Microsoft 儲存服務 | 已佈建的 v2 | HDD （標準） | GeoZone （GZRS） |
|
|
| Microsoft 儲存服務 | 已佈建的 v1 | SSD （進階版） | 本地 (LRS) |
|
|
| Microsoft 儲存服務 | 已佈建的 v1 | SSD （進階版） | 區域 (ZRS) |
|
|
| Microsoft 儲存服務 | 隨用隨付 | HDD （標準） | 本地 (LRS) |
|
|
| Microsoft 儲存服務 | 隨用隨付 | HDD （標準） | 區域 (ZRS) |
|
|
| Microsoft 儲存服務 | 隨用隨付 | HDD （標準） | 異地 (GRS) |
|
|
| Microsoft 儲存服務 | 隨用隨付 | HDD （標準） | GeoZone （GZRS） |
|
|
詞彙
在閱讀本文之前，可先了解與儲存體效能相關的一些重要詞彙：
每秒的 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。
延遲
延遲是延遲的同義字，並以毫秒為單位來測量。 延遲有兩種類型：端對端延遲和服務延遲。 如需詳細資訊，請參閱延遲。
佇列深度
佇列深度是儲存體資源一次可處理的擱置 I/O 要求數目。 如需詳細資訊，請參閱佇列深度。
根據使用模式選擇媒體層
Azure 檔案記憶體提供兩個記憶體媒體層，可讓您平衡效能和價格：SSD 和 HDD。 您可以在記憶體帳戶層級挑選檔案共享的媒體層，一旦您在特定媒體層中建立記憶體帳戶，您就無法移至另一個記憶體帳戶，而不需要 手動移轉至新的檔案共用。
在 SSD 和 HDD 檔案共享之間進行選擇時，請務必瞭解您打算在 Azure 檔案記憶體上執行的預期使用模式需求。 如果您需要大量的 IOPS、快速資料傳送速率或低延遲，則您應該選擇 SSD 檔案共用。
下表摘要說明 SSD 與 HDD 檔案共用之間的預期效能目標。 詳細資料請參閱Azure 檔案儲存體擴充性和效能目標。
| 使用模式需求 | SSD | HDD |
|---|---|---|
| 寫入延遲 (單一位數毫秒) | 是 | 是 |
| 讀取延遲 (單一位數毫秒) | 是 | 否 |
SSD 文件共享提供一種配置模型，可根據共享大小保證下列效能概況。 如需詳細資訊，請參閱佈建的 v1 模型 (部分內容可能是機器或 AI 翻譯)。
效能檢查清單
無論您是評估新工作負載或現有工作負載的效能需求，瞭解您的使用模式可協助您達到可預測的效能。
延遲敏感度： 對讀取延遲敏感的工作負載，且對終端使用者具有較高的可見度，更適合 SSD 檔案共用，這可為讀取和寫入作業提供單毫秒延遲（< 針對小型 I/O 大小為 2 毫秒）。
IOPS 和輸送量需求： SSD 檔案共享支援比 HDD 檔案共用更大的 IOPS 和輸送量限制。 如需詳細資訊，請參閱檔案共用級別目標。
工作負載持續時間和頻率： 相較於長時間執行且經常發生的工作負載，短（分鐘）和不頻繁的工作負載較不常達到 HDD 檔案共用的效能上限。 在 SSD 檔案共用中，當判斷應根據配置的儲存空間、IOPS 和吞吐量使用哪種效能設定檔時，工作負載持續時間是很有幫助的。 一項常見的錯誤是只執行幾分鐘的效能測試，結果通常會產生誤導。 若要取得實際的效能檢視，請務必以足夠高的頻率和持續時間進行測試。
工作負載平行處理： 對於平行執行作業的工作負載，例如透過相同用戶端上的多個線程、進程或應用程式實例，SSD 檔案共用提供比 HDD 檔案共用清楚的優勢：SMB 多重通道。 如需詳細資訊，請參閱改善 SMB Azure 檔案共用效能。
API 作業散發：中繼資料繁重的工作負載 (例如對大量檔案執行讀取作業的工作負載) 更適合 SSD 檔案共用。 請參閱中繼資料或命名空間繁重的工作負載 (部分內容可能是機器或 AI 翻譯)。
延遲 (Latency)
考慮延遲時，請務必了解 Azure 檔案儲存體如何判斷延遲。 最常見的度量是與端對端延遲和服務延遲計量相關聯的延遲。 使用這些交易計量，可藉由判斷應用程式流量在與用戶端的來回傳輸中花費多少時間，來協助識別用戶端延遲和/或網路問題。
端對端延遲 (SuccessE2ELatency) 是交易執行從用戶端、經由網路、到 Azure 檔案儲存體服務、回到用戶端的完整來回行程所花費的總時間。
服務延遲 （SuccessServerLatency） 是交易只在 Azure 檔案服務內往返所需的時間。 不包含任何用戶端或網路延遲。
SuccessE2ELatency 和 SuccessServerLatency 值之間的差異可能是由網路和/或用戶端所造成的延遲。
將用戶端延遲與服務延遲 (在此案例中為 Azure 檔案儲存體效能) 混淆很常見。 例如，如果服務延遲報告低延遲，而端對端報告要求有非常高的延遲，則建議所有時間都花在與用戶端的來回傳輸，而不是在 Azure 檔案儲存體服務中。
此外，如圖所示，離服務越遠，延遲體驗越慢，而且使用任何雲端服務達到效能調整限制就越困難。 從內部部署存取 Azure 檔案儲存體時，尤其如此。 雖然 ExpressRoute 之類的選項很適合內部部署，但仍然不符合在相同 Azure 區域中唯獨執行的應用程式效能 (計算 + 儲存)。
提示
使用 Azure 中的 VM 來測試內部部署與 Azure 之間的效能，是比較 Azure 連線網路功能的實際有效方式。 尺寸不足或未正確路由的 ExpressRoute 線路或 VPN 閘道可能會顯著降低在 Azure 檔案上運行的工作負載速度。
佇列深度
佇列深度是儲存體資源可服務的擱置 I/O 要求數目。 隨著儲存體系統所使用的磁碟從 HDD 主軸 (IDE、SATA、SAS) 演變為固態裝置 (SSD、NVMe)，也已演化為支援更高的佇列深度。 如果工作負載是由單一用戶端所組成，且該用戶端會與大型資料集內的單一檔案依序互動，就是低佇列深度的一個例子。 相反地，支援多個執行緒和多個檔案同時處理的工作負載可以輕鬆達到高佇列深度。 由於 Azure 檔案儲存體是一種分散式檔案服務，橫跨數千個 Azure 叢集節點，且設計用來大規模執行工作負載，因此建議您建置及測試具有高佇列深度的工作負載。
高佇列深度可以透過數種不同的方式，結合用戶端、檔案和執行緒來達成。 若要判斷工作負載的佇列深度，請將用戶端數目乘以檔案數目，再乘以執行緒數目 (用戶端 _ 檔案 _ 執行緒 = 佇列深度)。
下表說明可用來達到更高佇列深度的各種組合。 雖然您可以超過 64 的最佳佇列深度，但我們不建議這麼做。 如果這麼做，將不會再看到效能提升，而且因為 TCP 飽和而有增加延遲的風險。
| 用戶端 | 檔案 | 執行緒 | 佇列深度 |
|---|---|---|---|
| 1 | 1 | 1 | 1 |
| 1 | 1 | 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 毫秒 |
另請參閱
- 針對 Azure 檔案共用效能問題進行疑難排解 (部分內容可能是機器或 AI 翻譯)
- 監視 Azure 檔案儲存體 (部分內容可能是機器或 AI 翻譯)
- 規劃 Azure 檔案儲存體部署 (部分內容可能是機器或 AI 翻譯)
- 了解 Azure 檔案儲存體的計費方式 (部分內容可能是機器或 AI 翻譯)
- Azure 檔案儲存體定價