Cache Reserve seemingly does nothing, all stats are 0

Hello,

I activated Cache Reserve for hexstream.net (by far my most popular site) and my 4 other relevant domains a while ago.

I’m not sure it does anything at all, though, since all the stats for them have always been 0.
(Perhaps I missed a subtlety about how Cache Reserve works?)

(Note that I’m using Cloudflare Pages, perhaps there is no point in using Cache Reserve in that case?)

So, could anyone at Cloudflare please check what is up with my Cache Reserve?

I am on a free plan, so please feel free to help escalate this. Thanks!

edit: I found prior reports from November 2023, April 2023 and October 2022.

Interesting, before today I had never noticed that “The billable quantity is rounded up to the nearest million.”, in part because the initial documentation was not that clear about it, as it only mentioned it in passing in one example.

So the pricing for Cache Reserve effectively starts at 4.86$/month if it works at all, fortunately I was never charged for this since it has never worked at all for me so far…

My subscriptions mention that Cache Reserve is “0.00$ PLUS USAGE”, which is technically accurate but slightly confusing… Maybe Cache Reserve pricing should just be like Workers Paid whereby it officially starts at 5$/month and you get a lot of usage included? Of course, pricing like R2 whereby there is no minimum charge would be even better…

Anyway, I’m not sure if Cache Reserve would be worth it given my current revenue levels, but I’m willing to try it for at least a month if it gets fixed. I’m curious to see if the increased performance is worth it…

1 Like

Requirements are listed here Cache Reserve · Cloudflare Cache (CDN) docs

Most importantly assets need an edge ttl of larger than 10 hours, which is not the default.

I’d also check whether cacheable traffic is flowing through your account by checking the regular analytics.

Thank you for looking into this!

I can confirm that I am vastly exceeding all the requirements, I am caching an absolute ton and for a really long time!

Here is for instance my Cloudflare Pages _headers for ponies.hexstream.net (604800 seconds is 7 days, also note that I have Browser Cache TTL: Respect Existing Headers and a Cache Level: Cache Everything page rule for all my websites):

/*
! Cache-Control
Cache-Control: public, max-age=86400

/special/status.txt
! Cache-Control
Cache-Control: no-store

/*.png
! Cache-Control
Cache-Control: public, max-age=604800

/*.jpg
! Cache-Control
Cache-Control: public, max-age=604800

/*.gif
! Cache-Control
Cache-Control: public, max-age=604800

/*.webp
! Cache-Control
Cache-Control: public, max-age=604800

/*.svg
! Cache-Control
Cache-Control: public, max-age=604800

You can have a look at this SFW page with Chrome DevTools (F12), open the Network tab, perform a super refresh and check the headers… (Indeed, Cache-Control and Content-Length are appropriate…)

My analytics for hexstream.net confirm that I am indeed caching a ton…

I am quite sure Cache Reserve should cache more than 0 files in these circumstances… :slight_smile:

Cloudflare Pages maintains its own internal cache and implementing Cache Reserve on top of it actually would harm performance as it requires reads go to the backing R2 store instead of hitting the Pages backing KV store.

I am not aware of why Pages would cause Cache Reserve to not work, but I would caution that using the two together is not going to provide a performance benefit. Cache Reserve is designed to avoid expensive hits to your origin server.
I suppose there could be an argument in favour of this setup if you had a Pages Function you wanted to avoid hits to! As long as that Function isn’t hitting R2, because then you circle back around to pointless optimisations :stuck_out_tongue:

These headers would affect the browser TTL but not necessarily the Edge TTL. What are the contents of your Cache Rule or Page that is setting Cache Everything? You should include an Edge TTL with that rule. Cache Rules generally offer greater flexibility.

2 Likes

Ah, makes sense! Indeed I had alluded to that possibility:

So, since I use Cloudflare Pages for everything, I went ahead and completely disabled Cache Reserve across all my websites, and cancelled my subscription for it as well.

Thank you for the clear explanation, and I think the documentation for Cache Reserve should obviously mention this incompatibility between Cache Reserve and Cloudflare Pages…

My Page Rule is just the obvious thing, stuff like:

As for the Edge TTL, my understanding is that it will effectively just be inherited from the max-age in my case, which is exactly what I want.

I had initially wanted to tell Cloudflare to cache for much longer than the browser, but I ended the practice when I realized that leads to unintuitive and unwanted behavior.

As I told the CTO in an email on 6 march 2023 (coincidentally almost exactly a year ago):

So, I was looking to take advantage of a s-maxage much greater than max-age, so that Cloudflare would have much less revalidations to do from its side, while clients would revalidate with Cloudflare much more frequently. This seems optimal, since I can invalidate the Cloudflare cache anytime I want anyway, whereas clients would not normally refresh their cache before max-age has expired.

Intuitively, if I set a s-maxage of 30 days and a max-age of a day, I would expect that Cloudflare would revalidate with the origin every 30 days, while the client would revalidate with Cloudflare every day. I think this is what most people would expect, and this is what Cloudflare’s documentation seems to imply in multiple places.

Unfortunately, what these settings actually mean is that everything will be fine for the first day, but then for the next 29 days, Cloudflare will return a resource IT deems still fresh, but that THE CLIENT deems stale, causing endless revalidations! For instance, at day 10, Cloudflare will return a Age header that it deems still fresh for 20 more days, while the client will deem it to be stale by 9 days, so of course the client will try to revalidate it again the next time, and again, and again…

So currently, as far as I understand, using a s-maxage which is greater than the max-age is simply completely invalid. This should at the very least be documented, if validated. […]

Thank you for looking into this!

He said he was sending this to the cache team, I haven’t heard back since…

Anyway, sorry for the fun tangent! :joy:

I’m marking your reply as the solution, thanks again! :slight_smile:

1 Like

Hi @Hexstream, your topic has a solution here.

Let us know what you think of the solution by logging in and give it a :+1: or :-1:.


Solutions help the person that asked the question and anyone else that sees the answer later. Login to tell us what you think of the solution with a :+1: or :-1:.

This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.