每個 NetApp AFX 儲存節點都提供特定的讀取和寫入吞吐量。隨著節點加入叢集中，效能會線性成長，如本文件「節點效能的線性擴展」部分所述。

目前，節點類型為 "AFX 1K"，讀寫吞吐量大致如下所示。隨著 NetApp AFX 可用硬體的更新，這些限制可能會改變。注意：如下面的「基準測試結果」部分所示，使用多個客戶端讀取和寫入多個檔案時達到了最高效能。

每節點效能預估

每個儲存架包含高效能儲存架模組，配備 16 個 100GB 乙太網路連接埠，利用 RoCEv2 通訊實現與叢集中運算節點的高頻寬儲存互動。與任何實體資源一樣，這些儲存架的效能也有其極限——尤其因為 NetApp AFX 可以呈現多個指向同一組磁碟的節點。下表顯示了單一儲存架對 TLC 和 QLC 磁碟機的估計最大讀取和寫入效能。有關 TLC 和 QLC 差異的更多資訊，請參閱 "TLC 與 QLC"。

每個磁碟櫃的效能預估

在分散式 ONTAP 架構中，將儲存節點與磁碟櫃分離，可讓更多節點將流量推送到較少的磁碟櫃，這有助於減少資料中心的整體佔用空間，只需使用所需的容量即可獲得最大效能。

「效能密度」的概念使儲存管理員能夠最大限度地利用現有硬體，而無需過度配置儲存環境。

例如，在統一的 ONTAP 叢集中，由於每個節點都有自己的一組磁碟，因此效能僅限於該節點擁有的磁碟；由於只有一個節點可以存取一組磁碟，因此它不一定能充分利用可用磁碟並達到其最大效能。

統一 ONTAP – 效能劃分方式

NetApp AFX 將所有磁碟匯集到單一儲存可用區域中，因此所有節點都可以運用所有磁碟。而且由於磁碟和節點是分離的，因此您不需要那麼多機櫃就能獲得相同的效能。這樣可以壓縮效能並最大化機櫃的最大效能潛力。

NetApp AFX – 效能密度

Unified ONTAP 節點每個節點至少需要一組磁碟，且單一節點可以連接多個磁碟櫃。因此，單一節點可能會出現效能瓶頸，可能無法充分利用其自身的磁碟。

NetApp AFX 將所有磁碟櫃提供給所有節點。每個磁碟櫃包含具有 16 x 100GB RoCE 功能介面的模組，以增加每個磁碟櫃允許的總效能量。因此，您可以使用多個節點飽和單一磁碟櫃，這些節點將對同一組磁碟進行讀取和寫入。

截至 ONTAP 9.19.1，節點：機櫃飽和度比率約為 4:1。

以下部分介紹使用具有下列組態參數的 NetApp AFX 叢集進行基準測試的結果。

上述組態達到了 4 節點叢集可用的最大讀取速度（~134GB/s），並且正好達到每個節點允許的最大寫入速度（40GB/s）。

NetApp AFX – ElBencho 讀取效能，4 個節點

NetApp AFX – ElBencho 寫入效能，4 個節點

在媒體串流工作負載中，一部 4K 電影通常會分割成數萬個檔案，每個檔案的大小通常在 50 MB 到 250 MB 之間。每個檔案代表一個影格，應用程式會在單一要求中讀取整個影格。為了維持流暢、不間斷且無可見緩衝的串流，這些影格讀取必須完成且不能中斷。

ONTAP 提供磁碟區層級選項(`-aggressive-readahead-mode`來最佳化這些工作負載。從 ONTAP 9.19.1 開始，AFX 上引入了新的 `cross_file_sequential_read`模式，可加速具有可預測 I/O 模式的類似檔案類型工作負載（例如媒體轉譯和串流）。

cross_file_sequential_read 會根據檔案名稱預測下一個要讀取的檔案，並在用戶端發出讀取呼叫之前開始對這些檔案進行預先讀取。預測邏輯假設目錄中的所有檔案都遵循命名模式，其數字後綴單調遞增（例如 file1、file2、file3）。目錄中的所有檔案都必須遵循此模式，使用十進位或十六進位編號。檔案名稱長度最多為 255 個字元。此邏輯與副檔名無關，僅根據目前檔案名稱在目前目錄中產生下一組檔案名稱。如果先前使用十進位編號產生的檔案名稱在目錄中不存在，則會使用十六進位編號重新產生名稱。如果產生的檔案名稱都不存在，則不會對該組發出預先擷取。預先擷取會在發出下一個用戶端讀取時恢復。

啟用這些選項後，"frametest" 效能基準測試能夠以每秒 30 幀的速度讀取 30,000 個 4K 幀，同時支援 30 個用戶端（NFSv3 和 SMB3）和 34 個用戶端（NFSv4.1），沒有丟幀。

雖然跨檔案循序讀取主要針對媒體工作負載而設計，但其他具有可預測存取模式和檔案名稱的讀取密集型工作負載（例如 AI 訓練和推理）也可以從中受益。

幾十年來，NFS 版本 3 一直是 NFS 應用程式的黃金標準——早在 1995 年首次正式發佈時就已如此。它兼具效能和恢復能力，因此有充分的理由讓人們難以考慮升級到更新的 NFS 版本。

然而、NFSv3 並非沒有限制。協定的無狀態特性雖然有利於效能、並可將儲存容錯移轉的中斷降至最低、但對於資料一致性和鎖定管理而言並不理想。NFS 伺服器並不會真正追蹤鎖定狀態、因此如果發生故障、NFS 伺服器可能會或可能不會釋放鎖定、而 NFS 用戶端可能不知道檔案是否已鎖定。