Experiences with Glass Cache

In version 4, Glass Mapper introduced a caching mechanism to speed up access to mapped objects. Basically, once an object is mapped, it is stored in Glass Cache which by default utilizes HttpCache in Memory. The next time the same object is mapped, it will be returned from the cache instead of being read from the Sitecore database which in many cases speeds things up. The cache is cleared by publishing.

glass cache

Caveats

When reading things like “Glass has no performance issues anymore, they have caching now” made me want to check this out for myself. After all we would be introducing yet another caching layer to the several existing layers Sitecore already has.

I have evaluated the current implementation of Glass cache for the use in a large multisite solution with dedicated authoring and delivery instances. Models were being generated on the fly using TDS. In this scenario, I have found some shortcomings of the current Glass Cache implementation:

·         Glass Cache cannot be globally enabled / disabled via config

·         Enable / Disable cache on a model can only be done using code

Glass Cache cannot be globally enabled / disabled via config

On authoring instances, we wanted to globally disable caching. This is because authors were used to seeing what they edited in “normal” mode without having to publish.
Unfortunately, there is currently no safe way to globally disable Glass cache. An option would be to use the following code on application startup:

 // Caution: this doesn’t globally disable cache
 new DisableCache();

Unfortunately this leads to the issue that caching is re-activated in some cases when DisableCache() is used multiple times. For details see this ticket.

Update 06.11.2015:
According to Mike Edwards this issue is fixed and the fix will be part of next release of Glass Mapper.

Cacheable=true / false only via code

In this particular scenario, when generating models using TDS, we basically only have the option of enabling caching for ALL models or NONE at all. (add annotations in the T4 Templates)

Some more control over which Templates should be cached would be great. This can probably be accomplished by reading a property of the model prior to adding it to cache.

[SitecoreType(TemplateId=IMyTeaserTemplateConstants.TemplateIdString, Cachable = true)]
 public class MyTeaserTemplate : GlassBase, IMyTeaserTemplate 
 {
   ...

Speed testing!

I ended up testing several components built with Glass comparing loading times, finding that the difference between cached and uncached was relatively small. (Glass Cached components needed roughly 8% less time than uncached ones in my test). Of course, when accessing items very often i.E. hundreds of times in a row, Cached will be considerably faster but in a “day-to-day scenario”, i.E. a link list component with 10-20 links, the difference is insignificant in my opinion.

Sitecore HTML Cache for the win

When switching on Sitecore’s HTML Cache on a component, there is no difference between Glass Cached and uncached anymore. This is because the component’s code isn’t executed anymore on a cache hit, making the performance gain through Glass Cache even more insignifficant.

Conclusion

I love to use Glass Mapper especially since V4, but I currently don’t advise using Glass Cache. After all, Glass is already quite fast without it! I rather make use of Sitecore’s tried and tested HTML cache feature to speed up my components.

Any thoughts on this are highly appreciated. Feel free to comment or send me a message.


2 responses to “Experiences with Glass Cache”

  1. HI Mark,

    Awesome article. Can you please provide some scenario of when should we use glass cache with simple example?

Leave a Reply to Premkumar Cancel reply

Your email address will not be published. Required fields are marked *