ファイルサイズよりも、ファイルに対する `OPEN`呼び出しと `CLOSE`呼び出しの間に発行される書き込み回数の方が重要です。小さなファイルは本質的に `WRITE`呼び出し回数が少ないため、ライトバックには適していません。大きなファイルでは `OPEN`呼び出しと `CLOSE`呼び出しの間に書き込み回数が増える可能性がありますが、必ずしもそうとは限りません。

最大ファイル サイズに関する最新の推奨事項については、"FlexCache 書き戻しガイドライン"ページを参照してください。

クライアントからの書き込み時には、書き込み呼び出し以外にも、NASの変更を伴う呼び出しが行われます。これには以下が含まれますが、これらに限定されるものではありません：

SETATTR`および `SET_INFO`で `mtime、 atime、 ctime、 owner、 group、または `size`を設定する呼び出しは、キャッシュで処理されます。これらの呼び出しの残りはオリジンで処理する必要があり、操作対象のファイルについてライトバック対応キャッシュに蓄積されたダーティー データのライトバックをトリガーします。ライトバックが完了するまで、ファイルへのIOは休止されます。

これらの呼び出しがWANを経由する必要があることを理解しておくと、ライトバックに適したワークロードを特定するのに役立ちます。一般的に、上記の他の呼び出しが発行されることなく、 `OPEN`と `CLOSE`の呼び出しの間で書き込みを多く実行できるほど、ライトバックによるパフォーマンスの向上は大きくなります。

従来、リードアフターライトのワークロードはFlexCacheではパフォーマンスが低下していました。これは、9.15.1より前の動作モードがライトアラウンドモードであったためです。ファイルへの `WRITE`呼び出しは元の場所でコミットする必要があり、後続の `READ`呼び出しではデータをキャッシュにプルバックする必要がありました。その結果、両方の操作でWANのペナルティが発生していました。そのため、ライトアラウンドモードのFlexCacheでは、リードアフターライトのワークロードは推奨されません。9.15.1でライトバックが導入されたことで、データはキャッシュでコミットされ、キャッシュからすぐに読み取ることができるようになり、WANのペナルティが解消されました。ワークロードにFlexCacheボリュームでのリードアフターライトが含まれる場合は、キャッシュをライトバックモードで動作するように構成する必要があります。

ファイルのダーティー データがキャッシュに蓄積されると、キャッシュはデータを非同期的にキャッシュ元に書き込みます。この場合、当然のことながら、キャッシュ元へのフラッシュバックを待機しているダーティー データがあるファイルをクライアントが閉じるときに時間がかかります。閉じられたばかりでまだダーティー データが残っているファイルに対して別のオープンまたは書き込み命令が発行された場合、書き込みは、すべてのダーティー データがキャッシュ元にフラッシュされるまで中断されます。

FlexCacheがライトバック モードで動作する場合、レイテンシが増加するほどNASクライアントにとってメリットが大きくなります。しかし、ライトバックのオーバーヘッドが低レイテンシ環境で得られるメリットを上回ってしまうポイントがあります。一部のNetAppテストでは、キャッシュとオリジン間の最小レイテンシが8ms付近でライトバックのメリットが現れ始めました。このレイテンシはワークロードによって異なるため、ワークロードのリターン ポイントを必ずテストして把握してください。

次のグラフは、NetApp のラボテストにおける書き戻しのリターンポイントを示しています。 x 軸はファイルサイズ、 y 軸は経過時間です。このテストでは、NFSv3 を使用し、256KB の rsize および wsize でマウントし、WAN レイテンシは 64ms でした。このテストは、キャッシュとオリジンの両方に小規模な ONTAP Select インスタンスを使用し、シングルスレッドの書き込み操作で実施されました。結果は異なる場合があります。