300+ Personalization Rules – What to do with Sitecore Caching?

As we all know Sitecore provides us caching out of the box. Call it, Prefetch, Data, HTML, Item and so forth…You know what I am talking about. Sitecorians.. 🙂

This article mainly talks about how we can better improve our caching strategy in our projects/solutions especially when you have about 300+ Sitecore personalization rules. Have you had a chance to tackle a problem like this before?

Recently, I came across a problem where the page load (the response time from the server was too slow). I don’t actually recall what is the exact number, but let’s say it wasn’t up to the par. And with about 300 or more personalization rules (OOB, of course) the page was showing us bad results.

So, we started digging stuff. From, debug from XP to figuring out in chrome dev tools. We could not find what was the issue.

There was one catch though! The 300+ rules that we have. With 1-10, the page was rendering fine, but 300? C’mon! There has to be a better way, right?

In our components, we were using external calls with setting up the JSON data coming back in Application Cache. So, all the external calls where getting set in Application Cache. It was set to 500MB and expiration of 240 minutes. We also avoided any call to the DBs or any APIs directly. Everything is stored in Application Cache.

One of the advantages of using Application Cache is if you host Sitecore in Azure, it will use Redis for the same purpose. So, you don’t have to utilize Redis externally. It will be picked up Redis.

This was our base class in Foundation Layer:

public Boolean SetCache(String xCacheKey, T xCacheObj, int xcacheDurationInMinutes = 0)
 {
 Boolean bIsSuccess = false;
 if (xcacheDurationInMinutes.Equals(0))
 xcacheDurationInMinutes = _cacheExpirationTimeInMinutes;
 if (!_cache.InnerCache.ContainsKey(xCacheKey))
 {
 _cache.InnerCache.Add(xCacheKey, xCacheObj, TimeSpan.FromMinutes(xcacheDurationInMinutes));
 }

return bIsSuccess;
 }

And this is how we are calling from one of the classes from Foundation layer:

public TestForCache()
{
// Check if the API results are available in Cache.
string cacheKey = Settings.GetSetting(Constants.MyCache);
if (!string.IsNullOrWhiteSpace(cacheKey))
{
cacheKey += "_" + Sitecore.Context.Language;
// If the result is available in cache, return the result
var cacheResult = CacheManager.CacheManagerInstance.GetCache(cacheKey);
if (cacheResult != null)
{
return cacheResult;
}
}
// Continue since no cache exists.
var lang = (string.Compare(Sitecore.Context.Language.Name, Constants.ES_US, true) == 0) ? Settings.GetSetting(Constants.LanguageEspanol) : Settings.GetSetting(Constants.LanguageEnglish);
var result = ServiceHelper.GetJsonResult(Settings.GetSetting(Constants.CacheKeyAPI) + lang);
// Set API results in Cache
if (!string.IsNullOrWhiteSpace(cacheKey))
CacheManager.CacheManagerInstance.SetCache(cacheKey, result);
return result;
}

 

As you can see how we are calling the storing all the cache operations from Base to the calling functions. This decreased our TTFB (time to first byte) and the first-page load response is much much faster.

Hope you will get something out of this post 🙂