The new Read-Through and Write-Behind support in Windows Server AppFabric 1.1 allow developers to improve performance while at the same time reduce the complexity of their applications. This is done by moving the logic for reading from and writing to the database into the caching server itself.
Normally when a get request fails the client is responsible for loading the missing data from slow storage (e.g. a database, file server, or remote service) and populating the cache. This triples the number of round-trips needed for the request and introduces the possibility for a race condition. With Read-Through support turned on AppFabric itself makes the secondary call to slow storage. AppFabric gains this ability via a custom implementation of the abstract class DataCacheStoreProvider.
On the flip side, updating data requires sending changes to both the cache server and the slow storage. With Write-Behind support the client only needs to inform the cache server. The cache server will immediately acknowledge the update and then asynchronously update the slow storage. Again this requires a custom implementation of the DataCacheStoreProvider class.
AppFabric also offers features specifically designed for ASP.NET. The documented capabilities for the ApppFabric based ASP.NET session state provider are:
- It internally uses the NetDataContractSerializer class for session state serialization.
- It can store session state as a single blog or as individual items.
- It can share session state among different ASP.NET applications.
- It supports concurrent access to same set of session state for multiple readers and a single writer.
- It can use compression.
The “individual items” mode may offer the most significant advantage over previous versions in terms of performance, but it requires significant effort to use correctly. The basic idea is that only keys/value pairs that are actually needed are sent to the web server, thus reducing the penalty for storing large objects in the session. But this cannot be done blindly, lest you end up making far too many small requests. The solution is to group your session data so that related items are loaded at once. For example you may have a single “UserInfo” key instead of separate keys for the username, full name, and permissions. Another key may have a large object that is only needed on a single page or set of pages.
The output caching support in AppFabric is based on the “output cache provider extensibility point that was introduced in ASP.NET 4”. By shifting the cache from the web server to the caching server the number of pages one can cache is limited only by the size of the caching cluster. And unlike the default provider, the cache isn’t lost when IIS decides to recycle an AppDomain.
Like the session state provider, the output caching provider can use compression. Unfortunately what it cannot do is support Web Forms style control-level output caching. While the documentation doesn’t explicitly state it, there is an implication that this will be addressed in future versions.
The CTP of Windows Server AppFabric 1.1 is now available for x86 and x64 machines.