In this post I will try to describe the caching options that are available to you, to increase the responsiveness and the performance of your dynamic website build on top of the Dynamic Delivery for Tridion (DD4T) framework.
In a website build with DD4T (almost) all content comes from the Broker Database. The content is stored as an XML string in the database and is transformed (de-serialized) into .NET objects at request time. As you can image this has a huge impact on the performance of your website: on every request the XML is loaded (streamed) from the database and the DD4T framework de-serializes this into usable .NET objects.
This is a time-consuming process and puts a heavy load on your webserver.
Luckily there are a few options/strategies to improve the performance of your website. And the beauty about these options is that they (almost) come for free!
Output Caching
The first option is the out-of-the-box Output caching from ASP.NET.
Just decorate your controller (PageController, ComponentController; your choice) with the OutputCache attribute and your done!
[OutputCache(CacheProfile = "ControllerCache")]
public override System.Web.Mvc.ActionResult Page(string pageId)
{
...
}
And in your web.config you configure the duration of your ControllerCache:
<caching> <outputCacheSettings> <outputCacheProfiles> <add name="ControllerCache" duration="3600" varyByParam="*"/> </outputCacheProfiles> </outputCacheSettings> </caching>
OutputCache caches the output (…) for the duration you configured in the web.config. If the cache duration is set to 5 minutes, and in these 5 minutes you publish a page, the changes are NOT reflected in your browser if you hit F5. Only after 5 minutes the cache is invalided and on the next request the XML is loaded from the Broker Database. And de-serialized.
DD4T Caching
Luckily for us DD4T ships with a build in cache mechanism. This caching-mechanism is build on top of the .NET System Runtime Cache and can be used in conjunction with the Output Cache.
DD4T caching stores de-serialized objects like Components and Pages in the .NET Runtime cache after they are requested for the first time. Every consecutive request for that page/component loads it from the Object cache instead of loading it from the Broker database and de-serializing it into a .NET objects.
As you can imagine, this causes a massive performance improvement.
But how does DD4T ‘know’ when to invalidate the item in the cache? Because if you re-publish a page or component, you want your website to show the updated page/component.
The fact is that DD4T never knows when an item is republished, unless it ‘asks’ SDL Tridion for it. (Due to the fact that a website is stateless)
Well, this ‘asking’ is implemented in DD4T.
DD4T poll’s every x seconds/minutes/hours/etc (configurable) if the LastPublishDate from an item in the cache has changed. If it has changed (the item was republished) it will invalidate this item. The next time this item is requested, it will be loaded from the Broker databases, de-serialized and stored in the cache.
To configure how often DD4T needs to check the LastPublishDate of the items in the cache, use this setting in your web.config (value must be in seconds)
<add key="CacheSettings_CallBackInterval" value="30"/>
In this example, DD4T poll’s the Broker Database every 30 seconds to check if the items in the cache are still valid.
Also, after a configurable amount of time, the item is -no matter what- invalidated. The amount of time can be configured separately for pages and components.
Use the following configuration settings to accomplish this:
<add key="DD4T.CacheSettings.Page" value="3600"/> <add key="DD4T.CacheSettings.Component" value="3600"/>
In this example all the pages and components in the cache are invalidated after 1 hour.
SDL Tridion Object cache
SDL Tridion comes with a caching solution called ‘Object cache’. To quote the documentation, this is what it does:
To improve the performance of your Web site, you can choose to store the most commonly used or resource-intensive objects from your Content Data Store in a cache. The cache keeps these objects available for the applications that request them, rather than reinitializing them each time they are requested.
Pretty obvious right? So no need to explain it further.
Read the documentation here. (Login required)
More information about the SDL Tridion Object cache:
Finale notes
As we have discussed, there are 3 caching options available out of the box. Used them when needed, and tweak them according to your needs.
A very nice post about caching (and the performance you gain) with a SDL Tridion driven website was written by Nuno Linhares. Read it here: Tridion Content Delivery and Caching
I hope I gave you some information about caching in a dynamic (DD4T driven) website on top of SDL Tridion to get you started.
Albertromkes's Weblog 