The most expensive bottleneck in your application is asking for data from your SQL database. The fact of the matter is that it doesn’t matter is it doesn’t how many rows of data you request, the sheer request itself is costly.
The function below illustrates how easy it is to cache an object in DotNetNuke. It’s as simple as calling a standard function; checking in the cache if the value already exists; if not go get the data and then add it to the cache; return the cached object.
public static int GetInfoObject(int contentId)
{
var cache = DataCache.GetCache(Constants.ModuleCacheKey + Constants.ContentType + contentId.ToString());
if (cache == null)
{
var timeOut = 20 * Convert.ToInt32(Host.PerformanceSetting);
cache = controller.GetInfoObject(contentId);
if (timeOut > 0 & cache != null)
{
DataCache.SetCache(Constants.ModuleCacheKey + Constants.ContentType + contentId.ToString(), cache, TimeSpan.FromMinutes(timeOut));
}
}
return cache;
}
When you should cache an object
Any time you will need to request that action more than once in a user single request
Any time that data is likely not going to change for several user requests
Any time you are sorting or filtering the same collection of data multiple times.
When not to cache
When the amount of data exceeds the amount of memory on your server.
Data is only going to be access by one person every few days.
The point is that almost all data should be cached in some shape or form. If your application contains a forum with millions of entries then you obviously can’t cache them all. But perhaps then consider only caching the top 100 posts that 90% of your users are going to see every time they hit the homepage of your forum.
Reminders when caching
When adding or updating a row in your database. Make your SQL provider call as normal but have your business logic layer update that object into your cache as well. This will eliminate the need to make another return trip back to the database to get the same data.
DotNetNuke caching provider is capable of updating all web heads automatically with any changes to the cache
In my next blog I’ll discuss the benefits of client side caching.
