檔案大小比與呼叫檔案之間所發出的寫入次數來得小 OPEN CLOSE 。小型檔案本來就有較少的 WRITE 通話、因此不太適合回寫。大型檔案在與通話之間可能有更多寫入 OPEN CLOSE 、但這並不保證。

從用戶端寫入時、除了寫入呼叫之外、還涉及其他 NAS 呼叫：

這些通話必須在原始伺服器處理、並觸發在啟用回寫式快取中所累積的任何不乾淨資料的回寫。檔案的 IO 將會停止、直到回寫完成為止。

知道這些通話必須經過 WAN 、有助於識別適合回寫的工作負載。一般而言、在 OPEN `CLOSE`不發出上述其中一個通話的情況下、在與通話之間所能完成的寫入次數越多、效能回寫所提供的效能就越高。

寫入後讀取工作負載在 FlexCache 的執行效能一向不佳。這是由於 9.15.1 之前的繞過寫入操作模式所致。 WRITE`對檔案的呼叫必須在原始伺服器上進行、後續的 `READ 通話則必須將資料拉回快取。這會導致這兩種作業都會受到 WAN 的影響。因此、 FlexCache 在寫入模式中不建議使用寫入後讀取工作負載。在 9.15.1 中引入回寫功能後、資料現在會在快取中提交、並可立即從快取中讀取、免除 WAN 的麻煩。如果您的工作負載在 FlexCache 磁碟區中包含讀取後寫入、則應將快取設定為以回寫模式運作。

當檔案在快取中累積髒資料時、快取會以非同步方式將資料重新寫入來源。這自然會導致用戶端關閉檔案、但仍有髒資料等待重新排清來源。如果剛關閉且仍有髒資料的檔案有其他開啟或寫入資料、寫入作業將會暫停、直到所有髒資料都已排清至來源。

當 FlexCache 以回寫模式運作時、延遲增加對 NAS 用戶端更有幫助。不過、回寫的成本、有一點比低延遲環境中所獲得的優勢還要高。在某些 NetApp 測試中、回寫效益是從快取與原始伺服器之間的最低延遲開始、時間為 8 毫秒。這種延遲會因工作負載而異、因此請務必進行測試、以瞭解您的效益回報點。

下圖顯示 NetApp 實驗室測試中回寫的退回點。 x`軸為檔案大小、 `y 軸為經過時間。此測試使用 NFSv3 、以 256 KB 和 64 毫秒的 WAN 延遲進行掛載 rsize wsize 。此測試是使用小型 ONTAP Select 執行個體來執行快取和原始伺服器、以及單一執行緒寫入作業。您的結果可能有所不同。