Windows Server AppFabric 1.1のリードスルーとライトビハインドのサポートによって、性能が改善し複雑なアプリケーションがより単純になる。読み取りと書き込みの処理をキャッシュサーバ自体が行うようになるからだ。
普通読み取り処理が失敗した場合、クライアント自身が遅いストレージ(例えば、データベースやファイルサーバ、リモートサービスなど)から読み取れなかったデータを読み出してキャッシュに追加しなければならない。この場合、1回の読み取り処理に3倍のラウンドトリップが必要になり、競合状態を生み出す可能性がある。しかし、リードスルーをサポートしたことによって、AppFabric自身が2回目のデータ読み取りを行うようになる。このサポートを有効にするには、抽象クラスDataCacheStoreProviderを継承して自前で実装する必要がある。
一方、更新処理はキャッシュサーバと遅いストレージの両方を更新しなければならない。しかしライトビハインドのサポートされると、クライアントはキャッシュサーバにだけ更新を通知すれよくなる。キャッシュサーバはその通知をすぐに検出して非同期で遅いストレージを更新する。ただし、これもDataCacheStoreProviderを自前で実装する必要がある。
また、AppFabricはASP.NETに特化した機能も提供する。ドキュメントによれば、ApppFabricを使ったASP.NETのセッションステートプロバイダが提供するのは、
- 内部的にはセッション状態のシリアライゼーションにはNetDataContractSerializerクラスを使う
- セッション状態は単一のバイナリデータとして保存するか、個別のアイテムとして保存できる
- 異なるASP.NETアプリケーション間でセッション状態を共有できる
- 複数の読み取り処理や単一の書き込み処理向けにセッションへの並列でのアクセスをサポートする
- 圧縮できる
前バージョンと比べた場合、“個別のアイテム”としてセッション状態を保存する方式は性能面で大きな利点となる。しかし、この方式を正確に扱うのは大変だ。必要なキー/値のペアだけウェブサーバに送信することで、大きなオブジェクトをセッションに保存した場合の不利益を低減するというのがこの方式の基本的な考え方だ。しかし、何も考えずに実装して、結局小さなリクエストを大量に飛ばすことにならないようにする必要がある。セッションデータをまとめて、関連するデータを一度にロードできるようにするのが解決策になるだろう。例えば、ユーザ名やフルネーム、権限などを別々のキーとして持つのではなく単一の“UserInfo”キーとして持つ。そして、あるひとつのページや複数のページにまたがって必要な大きなオブジェクトは別のキーにして保存する。
AppFabricの出力のキャッシングのサポート “ASP.NET 4で導入された出力キャッシュプロバイダの拡張ポイント”をベースにしている。キャッシュがウェブサーバからキャッシュサーバに移行することで、キャッシュできるページ数はキャッシュクラスタの数にだけ制限されるようになる。また既定のプロバイダと違って、IISがAppDomainをリサイクルしてもキャッシュは失われない。
セッション状態プロバイダと同じように、出力キャッシュプロバイダも圧縮できる。しかし、残念ながらフェブフォームスタイルのページのコントロールレベルの出力のキャッシュはできない。このことはドキュメントには明示的に書いていない。将来のバージョンでは対処されるのかもしれない。
Windows Server AppFabric 1.1のCTPはx86とx64の両方のマシンで利用できる。