Does Stale Page Cache eliminate re-renderings for less frequent requests?

Hello,

I’d be much obliged if someone with good knowledge of page caching could clarify the below questions for me. Apologies for the wall of text but it’s a complex topic.

Question

Does the user have to wait for page to re-render, if their request is the first to hit the page after it’s expired in the First Level Page Cache (FLPC), even though it is available in Stale Page Cache (SPC)?

To clarify the question (please see one in Conclusion section as well):

Background/scenario

I have a bunch of complex pages that take long time to render. They are not accessed very frequently (couple of times a day, perhaps). My objective is to reduce the number of times pages are re-rendered (down to zero or close to zero), in order to:

  • prevent users from having to wait,
  • reduce computing and heap cost of rendering.

Stale Page Cache initially sounded like a good way to achieve this, but on closer look I now have doubts whether this is the case.

Based on the documentation and my own tests, I understand that the following behaviour takes place:

  • With:
    • FLPC and SPC are enabled; SPC with much longer TTL than FLPC,
    • a non-expired, long-lived entry is present in SPC for a page,
    • corresponding entry in FLPC has expired.
  • User requests the page (the first request after the FLPC expiry).
  • Page is loaded from SPC to FLPC.
  • Re-rendering is triggered for the current user, and their request is blocked until the page is re-rendered.
  • Re-rendered content is stored in SPC.
  • Re-rendered content is returned to the user.

Conclusion

With requests for the same page coming at intervals longer than FLPC TTL, it seems that they will always trigger re-rendering and will always be blocked. This is exacerbated when FLPC is purged on any content change (a frequent thing in my system) as it, effectively, further reduces TTL in FLPC.

If that is the case, it seems to me that the First Level Page Cache and Stale Page Cache are designed with thundering herd protection as their primary (only?) concern and that they do not eliminate the need to re-render pages for less frequent, more isolated requests.

Is the above scenario and my conclusion correct?


References

From Understand HST Enterprise Caching about Stale Page Caching:

Stale Page Caching allows the delivery tier to serve a lot of visitors a stale page while just 1 visitor is waiting for the recreation of the page. After the cached page is ‘refreshed’ with the recreated one, all new visitors will get the fresh page.

…the visitor whose request was used to restore the page from the stale cache is still being processed to render a fresh version of the page. Once it is finished, it stores the fresh version of the page in the First Level Cache and in the Stale Page Cache (and in Second Level Cache if the Second Level Cache is available).

Kind regards,
Rafał

Hi Rafał,

All your reasoning is spot on! The page cache is designed with two goals in mind:

  1. thundering herd protection
  2. make frequently requested pages extremely fast (as in > 10.000 pages per/req on the BE)

Your use case is different. The stale page support helps that even if a page is evicted from cache, that when concurrent new requests come in, only the first one is used to generate the new page and other requests get the stale version until the first request finishes and replaces the cached version. But that won’t support what you need. A more complex setup uses redis as secondary cache: then you can cache pages with eg a TTL of hours, but for the long tail infrequently requested pages, that still won’t give you what you need. For that you’d have to resolve to some crawler refreshing the page cache every x time.

Hope this helps,

Regards Ard

1 Like

This helps MASSIVELY, @ard.schrijvers.

For a while I was stuck on my early, incorrect assumptions about Stale Page Caching, and only close look and detailed testing help me understand what the documentation was saying from the beginning (the second of the snippets quoted above).

You’ve just removed a substantial anxiety I had over my misunderstanding of this thing.

Thank you so much for taking the time to respond; I appreciate it a lot :+1:

Hi Rafał,

Thanks for your feedback and good findings, as said, you were spot on :slight_smile:

Hope you can get your requirements to work for you with the tooling we have.

Regards Ard