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 ūüôā

Advertisements

Why you need Helix in your solution?

While back, I created a poll on whether if you prefer Helix vs. Non-Helix approach to the solution and most of you had an inclination towards creating a scalable, yet modular structure with Helix principles. The term Helix was coined long time ago which means decoupling of the projects (simple!). In the dictionary, it goes something like this:

“an object having a three-dimensional shape like that of a wire wound uniformly in a single layer around a cylinder or cone, as in a corkscrew or spiral staircase.”

Think you got the gist? No?¬†Alright, moving on…

 

For the solutions that I have implemented on Helix, these are my findings. Hope you share and provide your thoughts as well:

1. Clean:¬†Now, when I say clean, it doesn’t mean that cleaning your house or anything, but to able to scope out the code in a breath of time. Clean n Clear (not the face wash) solutions were always part of solution designing from the dawn of software development. Every person who is involved in software will tell you to make their projects clean and easy to understand. That is why I highly recommend the book¬†Clean Code: A Handbook of Agile Software Craftsmanship: Robert C. Martin: 9780132350884: Amazon.com: Books¬†This book really shines the way how you design classes, functions, variables, etc.

Helix focuses on this. To make solution clean and easily identifiable.

2. Scalable: For any project that you want to do in software life cycle, you always want to make it scalable. Which means, it can extend or grow. In Sitecore terms, it means are you thinking of extending the solution to accept any multisite capabilities, outside caching strategy, external logging mechanism, language providers, 3rd party integrations, etc. Helix principles provide a way to extend your classes, functions, projects in a single solution.

3. Faster time to market:¬†Anytime in any software application, you have to change something, build something, roll-off, bug fixes as quickly as possible and make it live. With Helix, it is easy to take care of requests like these. Everything is modular and flexible. Need to find and fix the bug =¬†check! Need to extend some classes from Sitecore Kernel library =¬†Check! It’s not as easy as it sounds (but you get the point).

4. Technical Roadblocks:¬†How many times you have seen in the old software age that whether a class is too extended and is written in a millions line of code? Can you read it? Can you interpret what’s being written? Its hard, I get it. Technical roadblocks, or sometimes I say “Bad Code Written”, occurred a lot of times in our lives where we are stuck and cannot go anywhere. Either we have to start from scratch or…? I don’t have any other solution to this. With Helix, there are no technical roadblocks. Everything is scalable and easy to read. Making architecting fun!

5. Modular:¬†Did I mention Modular in previous points? I don’t think so. Here it is: Having a modular structure always help to define which projects can be called as separate. One important thing to notice here is that not all the components you see on the page are features/modules. But, one key thing to note is that they are always acting as a separate entity. That is the power of calling them modular. If you have a Navigation, make it a separate project. If you have a Hero Carousel, make it a separate project.

In a nutshell, I think for every project, there are customizable solutions. But, at the core, it can all remain the same.

Well..these are the main points that I thought which make Helix easy to deal with and my life too  In the next, I will provide a tech whitepaper on a recent project we did using Sitecore 9 and SXA.

More to come…

Sitecore DB Tweak

Some simple adjustments to the configuration of SQL Server can greatly improve the performance of the database environment.  Keep in mind that some of these settings may impact the backup approach you employ for MS SQL.

  1. Set the compatibility level to SQL Server 2008 (100) to take advantage of the latest optimizations.
  2. Ensure the auto-close property is set to false. This ensures that a page will only make one connection.
  3. Ensure the auto shrink property is set to false to avoid costly dynamic resizing.
  4. Ensure the recovery model is set to simple to avoid the high overhead of transaction logs.

Sitecore Helix Knowledge Base

I am trying to consolidate links for the Helix approach that Sitecore folks have created:

http://helix.sitecore.net/index.html (You should definitely start here!)

http://helix.sitecore.net/introduction/index.htm

http://sitecoreblog.evident.nl/posts/2017/02/20/helix-in-practice-

https://sitecorebasics.wordpress.com/2017/02/17/sitecore-helix-basics/

https://github.com/Sitecore/sitecore.demo

http://habitat.demo.sitecore.net/ (Habitat demo site)

https://github.com/Sitecore/Habitat (Habitat Git)

Feel free to add your links in the comments section.

#Sitecore