Manh Nguyen
Sep 4, 2024
  275
(1 votes)

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
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:

  1. API Controller Action
  2. Model Builder Logic
  3. Query logic for Search & Navigation, Graph or some other Search Provider
  4. 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:

  1. Use Lazy Dependency Resolution to reduce resource consumption
  2. Cache just the final constructed model which will likely be leaner than the S&N cache
  3. Cache any extra information resolved between model building and search logic
  4. Remove duplicate model and query building effort.
  5. 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
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.
Latest blogs
SEO redirects in .NET + Optimizely

Nice and easy way to add necessary SEO redirects

Damian Smutek | Oct 14, 2024 | Syndicated blog

Multiple Anonymous Carts created from external Head front fetching custom Api

Scenario and Problem Working in a custom headless architecture where a NextJs application hosted in Vercel consumes a custom API built in a...

David Ortiz | Oct 11, 2024

Content Search with Optimizely Graph

Optimizely Graph lets you fetch content and sync data from other Optimizely products. For content search, this lets you create custom search tools...

Dileep D | Oct 9, 2024 | Syndicated blog

Omnichannel Analytics Simplified – Optimizely Acquires Netspring

Recently, the news broke that Optimizely acquired Netspring, a warehouse-native analytics platform. I’ll admit, I hadn’t heard of Netspring before,...

Alex Harris - Perficient | Oct 9, 2024 | Syndicated blog