Episerver performance–Part 1 Object Cache
When to use object caching
Object caching is great when you are getting data from external systems, like fetching pressreleases from another site like myNewsDesk, getting products from a PIM or similar. These calls are generally very slow and requesting fresh data every time might not be needed.
Memory Cache, Static Dictionary or Episerver Cache
The .NET memory cache in System.Runtime.Caching is a great tool but if you decide to use it, make sure you are not ever going to use load balancing for your websites. To invalidate cache on one server is pretty difficult to get working correctly. For multiple servers, you really want support out of the box like you get with EPiServer Cache.
A static dictionary can work in a similar way in solutions to store data across calls. The problems here is that you need to be sure that you won’t get into memory problems for storing large amounts of data. Caches have a lot of functionality around this problem. For small amounts of data, storing them in a static dictionary can work but with the same problem with load balancing as above for the standard .NET cache.
Episerver caching now resides under the interesting name ISynchronizedObjectInstanceCache. The old CacheManager is now dead. The new implementation is easy to get from the ServiceLocator and to use and you can follow the guide here:
I want to highlight a few nice additions they have done. Master keys are new and work like a grouping of cached items. This means that it’s easy to divide your cache into multiple sections like “users”, “products” and similar and only kill the part of the cache you need when something is updated. This is really useful in many scenarios.
To get full benefit from Episervers object caching you also want to configure cache invalidation events for load balanced servers. You can read more about that here
To cache or not to cache… – Hamlet
Don’t use object caching if you are simply getting current page, getchildren from the CMS. This is cached already 99% of the time so the cost for these operations are normally very small if you aren’t adding something expensive on top. Measure performance before you cache anything. Caching adds an extra layer of complexity to any solution. Caching menues is normally a bad idea since the menu depends on what user is logged in. Normally you don’t need to cache this and if you do, only cache it for anonymous users.
Best practice tips about caching
Log everything
I would really recommend adding extra logging to all cache logic that specifies whether something is gotten from the cache or not.
Make it possible to get fresh from data source
Include a parameter to your cached method that forces a fresh copy from the data source..
Make it possible to change/disable cache
Preferably as an admin or at least in config files
Think about the first hit
If you want to avoid the first user having a huge load time while the cache is still empty, why not load the data with a scheduled job? You did add that extra parameter for getting fresh from data source right? Then setting up a scheduled job that triggers update will be a piece of cake.
Don't underestimate the complexity of caching
Caching stuff is easy. But it's like a sawed-off shotgun. It's easy to kill someone else by mistake than the one you are aiming at. Give some extra love to choosing the correct cachekeys that includes all parameters and set up the correct cache invalidation. It’s a steady source of errors in solutions that are quite tricky to find later without decent logging.
I’ll dive in to some heavy code later in this blog series but the links above are enough for getting caching to work.The coding part for basic object caching is pretty trivial. I’ll add some examples for the more advanced variants in the next blogs
Comments