Default caching on search request on Search & Navigation

For the better performance, Search & Navigation .Net client has provided StaticallyCacheFor method for caching your search result in a specific of time span. It really useful when you perform a real-time search response to your users without a request.

We now including a default caching duration for your search request in-case StaticallyCacheFor make your code more cumbersome 😃

This can be done by setting DefaultSearchCacheDuration (in seconds) in Find section and it applies to all request that calling to GetResult or GetContentResult (in both asynchronous and synchronous version of API).

    "Find": {
      "DefaultIndex": "your_index",
      "ServiceUrl": "https://service.find.episerver.net/your_private_key",
      "DefaultSearchCacheDuration": 300
    }

In the example above you config for default caching in 5 minutes, but you can overide this default value for some specific request by using StaticallyCacheFor, this will replace default value as highest priority.

For example:

//this response will cache the search result by 5 minutes as DefaultSearchCacheDuration is set to 300 seconds.
var responseCacheInDefault = await SearchClient.Instance
.Search<IContent>().For("samsung")
.GetResultAsync();

//but this response will be cached in 15 minutes
var responseCacheOverridden = await SearchClient.Instance
.Search<IContent>().For("iphone")
.StaticallyCacheFor(TimeSpan.FromMinutes(15))
.GetResultAsync();

If you don't have DefaultSearchCacheDuration in the Find config and don't also set StaticallyCacheFor, your search response will automatically cache in 10 minutes.

But maybe you ask for "what if I don't need any default search cache?", just set DefaultSearchCacheDuration to zero.

For more details please go to our documents for developers.

Please don't hesitate to contact us if you have any question or feedback.

Sep 04, 2024

Comments

Mark Stott Sep 4, 2024 08:52 AM

Thank you for sharing Manh. It's good to know that this now exists.

In terms of search and application performance consider taking that one step further and instead ignore caching at the Search and Navigation layer and bring caching further up the stack.

e.g.

Assuming you have an API within your CMS build that surfaces search results to the UI without exposing the index or business logic. This will typically have classes to fulfil the following roles:

API Controller Action
Model Builder Logic
Query logic for Search & Navigation, Graph or some other Search Provider
Search Result Model (Containing a subset of properties to render as search results)

In this scenario you should look at introducing caching at the entry point to the controller action. Create a unique cache key based on the query parameters. Use this first to retrieve the model for the search result. If this doesn't exist in cache, then access the search logic and model builders to get and construct your results, add this to cache before returning the result to the UI.

By shifting the caching to the entry point of the controller, you can do the following:

Use Lazy Dependency Resolution to reduce resource consumption
Cache just the final constructed model which will likely be leaner than the S&N cache
Cache any extra information resolved between model building and search logic
Remove duplicate model and query building effort.
Cache becomes agnostic of the index type.

Downside, it will be a single cache object per query combination and agnostic of user permissions, which for builds without user logins would be largely inconsequential.

Manh Nguyen Sep 5, 2024 02:41 AM

Thank you Mark for your very nice idea. We can improve the cached strategy in the near future.👍

Please login to comment.