Widget caching not working as expected

We've developed a quick widget that reads some HTML using $core_v2_http.Get, then outputs it into the widget body, e.g.

#set($fileURL = "SOME_SERVER/${filename}.html")
#set($fileResponse = $core_v2_http.Get($fileURL, "%{ Headers = $headers, BypassUrlFiltering = 'false', IsCacheable = 'true', TimeoutSeconds = '5', VaryCacheByUser = 'false' }"))   

#if ($fileResponse.StatusCode==200)
    $fileResponse.Response
#end

As you can see in the snippet, IsCacheable is true in the .Get parameters.

We are also setting the widget itself to cacheable..

The widget displays the contents of that file fine, but it's not cached.. I can go & change the file contents and it's instantly updated in the widget, leading me to believe it's making the .Get request on every page view & isn't using the cache at all.

We have IsCacheable set in the .Get parameters AND in the widget. DevMode is not enabled on this environment.

What am I doing wrong?

Top Replies

Parents

0 Ben Tiedt over 2 years ago

When caching is enabled on the request and VaryCacheByUser is false (or the user is anonymous) and the HTTP response does not specify Cache-Control: no-store, the response will be cached for the max-age value of Cache-Control from the response or, if no max-age is provided, 30 minutes. The cache key will be formed by the URL, headers, and any post data (so any variation will cause a cache miss).

Any response that is cached is not guaranteed to be kept in the cache for its full cache duration as the cache can be pruned to size based on usage as needed.

What is the value of the Cache-Control header for the URL you're requesting?
Cancel
Vote Up 0 Vote Down

Sign in to reply

Verify Answer

Cancel

Reply

0 Ben Tiedt over 2 years ago

When caching is enabled on the request and VaryCacheByUser is false (or the user is anonymous) and the HTTP response does not specify Cache-Control: no-store, the response will be cached for the max-age value of Cache-Control from the response or, if no max-age is provided, 30 minutes. The cache key will be formed by the URL, headers, and any post data (so any variation will cause a cache miss).

Any response that is cached is not guaranteed to be kept in the cache for its full cache duration as the cache can be pruned to size based on usage as needed.

What is the value of the Cache-Control header for the URL you're requesting?
Cancel
Vote Up 0 Vote Down

Sign in to reply

Verify Answer

Cancel

Children

0 Matt over 2 years ago in reply to Ben Tiedt

Good point re. the cache control on the URL being requested. That was something I needed to sort out.

So 'IsCacheable' on the $core_v2_http.Get respects the headers from the target webservice, which makes sense.

However, I'm still confused as to why the Widget's cache isn't kicking in.. that would surely cache the full widget HTML rendered body, or is it also doing something fancy, like looking inside the Velocity being executed & deciding when to cache the content?
Cancel
Vote Up 0 Vote Down

Sign in to reply

Verify Answer

Cancel
+1 Ben Tiedt over 2 years ago in reply to Matt

The IsCacheable flag on the widget only caches for 5 seconds (because there are many potential dependencies that cannot be monitored, the cache can't last long). 5 seconds doesn't seem like much but in a high load environment it can have a significant impact.
Cancel
Vote Up +2 Vote Down

Sign in to reply

Reject Answer

Cancel
0 Matt over 2 years ago in reply to Ben Tiedt

Ohhhh, now I never knew that. Okay, well this makes sense then. I'll let our devs know so that they bear this in mind.

Btw. the http.Get is behaving as expected now we've set the cache headers appropriately.

Thanks!
Cancel
Vote Up +1 Vote Down

Sign in to reply

Verify Answer

Cancel