World is now on Opti ID! Learn more

dada
Jan 25, 2019
  88
(0 votes)

Common Find caching pitfalls

Under certain conditions, the cache duration set with .StaticallyCacheFor(minutes) does not last as long as specified.
There are three common reasons for this.

More on .StatisticallyCacheFor can be found here
https://world.episerver.com/documentation/developer-guides/find/NET-Client-API/searching/Caching/


.Filter() on a datetime property

Any .Filter() on a datetime property with second (or finer) resolution should be rounded up to the nearest minutes matching the wanted cache duration. As the cache key is based on the query payload we don't want it to change more frequently than the cache duration otherwise we will rarely utilise the cache as a new cache is generated for every request and a new request sent to the Find service. 

Here is an example of such a filter extracted from the JSON sent to the _search endpoint. You could inspect your requests with Fiddler.

"range": {
"EndDate$$date": {
"from": "2019-01-24T20:59:59Z",
"to": "9999-12-31T23:59:59.9999999Z",
"include_lower": false,
"include_upper": true
}
}


.FilterForVisitor()

.FilterForVisitor is a set of filters including .ExcludeDelete, .PublishedInCurrentLanguage, and .FilterOnReadAccess.

.PublishedInCurrentLanguage contains a filter on a datetime and as such is affected by the same issue described in point #1.

In a later version of Find (13.1) the datetime sent through to the .PublishedInCurrentLanguage() method uses a NOW() function instead of an actual value and is therefor not affected by this.

If on an earlier version, replace .FilterForVisitor() with the individual filters and round up the datetime used with PublishedInCurrentLanguage() just as you would have if you've used a custom datetime filter as pointed out earlier.

.GetContentResult()

When using .GetContentResult() unlike .GetResult() there is a cache dependency on published content. If there are any updates cache will be evicted. For Commerce sites updates are typically frequent and could therefore have a negative impact on cache.

Our recommendation is to use a custom .GetContentResult() where cache with this dependency is bypassed. This is commented out here.
Don't forget to add your .StaticallyCacheFor() to control the cache duration.


public static IContentResult<TContentData> GetContentResult<TContentData>(this ITypeSearch<TContentData> search, int cacheForSeconds = 60, bool cacheForEditorsAndAdmins = false)
where TContentData : IContentData
{
if (typeof(IContent).IsAssignableFrom(typeof(IContent)))
{
search = search.Filter(x => ((IContentData)x).MatchTypeHierarchy(typeof(IContent)));
}
var projectedSearch = search
.Select(x =>
new ContentInLanguageReference(
new ContentReference(((IContent)x).ContentLink.ID, ((IContent)x).ContentLink.ProviderName),
((ILocalizable) x).Language.Name));

//Apply caching for non-editors
//if (cacheForEditorsAndAdmins || !(PrincipalInfo.HasEditAccess || PrincipalInfo.HasAdminAccess))
//{
// var cacheSettings = ServiceLocator.Current.GetInstance<IContentCacheKeyCreator>();
// projectedSearch = projectedSearch.StaticallyCacheFor(TimeSpan.FromSeconds(cacheForSeconds), new CacheDependency(null, new string[] { cacheSettings.RootKeyName }));
//}

var searchResult = projectedSearch.GetResult();

var contentRepository = ServiceLocator.Current.GetInstance<IContentRepository>();
var fetchedContent = new Dictionary<ContentInLanguageReference, IContent>();
foreach (var language in searchResult.GroupBy(x => x.Language))
{
foreach (var content in contentRepository.GetItems(language.Select(x => x.ContentLink).ToList(), new LanguageSelector(language.Key)))
{
fetchedContent[new ContentInLanguageReference(content)] = content;
}
}

var sortedContent = new List<TContentData>();
foreach (var reference in searchResult)
{
IContent content;
if (fetchedContent.TryGetValue(reference, out content) && content is TContentData)
{
sortedContent.Add((TContentData)content);
}
else
{
log.WarnFormat("Search results contain reference to a content with reference \"{0}\" in language \"{1}\" but no such content could been found.", reference.ContentLink, reference.Language);
}
}

return new ContentResult<TContentData>(sortedContent, searchResult);
Jan 25, 2019

Comments

Please login to comment.
Latest blogs
Make Global Assets Site- and Language-Aware at Indexing Time

I had a support case the other day with a question around search on global assets on a multisite. This is the result of that investigation. This co...

dada | Jun 26, 2025

The remote server returned an error: (400) Bad Request – when configuring Azure Storage for an older Optimizely CMS site

How to fix a strange issue that occurred when I moved editor-uploaded files for some old Optimizely CMS 11 solutions to Azure Storage.

Tomas Hensrud Gulla | Jun 26, 2025 |

Enable Opal AI for your Optimizely products

Learn how to enable Opal AI, and meet your infinite workforce.

Tomas Hensrud Gulla | Jun 25, 2025 |

Deploying to Optimizely Frontend Hosting: A Practical Guide

Optimizely Frontend Hosting is a cloud-based solution for deploying headless frontend applications - currently supporting only Next.js projects. It...

Szymon Uryga | Jun 25, 2025

World on Opti ID

We're excited to announce that world.optimizely.com is now integrated with Opti ID! What does this mean for you? New Users:  You can now log in wit...

Patrick Lam | Jun 22, 2025

Avoid Scandinavian Letters in File Names in Optimizely CMS

Discover how Scandinavian letters in file names can break media in Optimizely CMS—and learn a simple code fix to automatically sanitize uploads for...

Henning Sjørbotten | Jun 19, 2025 |