High number of requests to origin for the same resource

Can you post the URL to that resource?

Yes of course:

This is an example with the query string appended to it:

The query string exclude doesn’t work for me, if I increment the value of _ I’m getting a cf-cache-status: MISS

The cache itself works, requests for already requested URLs return a hit, however as Stephane mentioned the query string exclusion does not take effect.

Check that once more.

Found the issue, you’ve got a page rule for the wilcard affecting a different level of caching and this page rule takes the precedence.

I’d suggest you change the cache everything for an Origin Cache Control and we’ll respect the cache-control implementation sent by your Origin with excluding the query string from the cache key

Wow, that seemed to fix it - THANKS for world class support :smiley:

Wouldn’t it also be fine to just disable the page rule?

1 Like

No worries :slight_smile:

No you can’t as CF just cache a specific list of extensions by default, you want to activate Origin Cache Control to raise your caching ratio - https://support.cloudflare.com/hc/en-us/articles/200172516-Which-file-extensions-does-Cloudflare-cache-for-static-content-

Thanks @sandro for jumping on this too, appreciated! Nice team work :slight_smile:

1 Like

That makes sense - thank you.

I’ll mark this as solved.

Hi hope its ok to ask here, you are saying that with argo enabled, when something got cached in datacenter x its got propagate to all Cloudflare datacenters?

because I don’t think it actually happening

Hey @boynet2,

That’s not exactly that, with Argo tiered caching, we do elect some Tier 1 POP authorised to talk to the Origin and all Tier 2 will talk to those Tier 1 to get Asset they don’t have in their own cache. That’s not a proper propagation, a request needs to come to a Tier 2 to effectively have this asset in the local cache.

Why are you asking? Could you share with me your configuration? Argo has 3 components so saying Argo activated isn’t enough, I need to know which component is activated on your domain:

  • Smart Routing
  • Tiered Caching
  • Tunnel

I hope it makes sense,

I just have traffic -> argo turned on, where do I enabled Tiered Caching?(I am on pro plan)

I am asking because my urls ttl are short(1 minute) and I really try to lower my miss rate, because my site requests are evenly divided in 5-6 locations I am seeing a lot of misses, I am working right now on some worker to help me with that, but what you described could help me

I’ve your solution here :slight_smile:

You could leverage the stale-while-revalidate origin cache-control directive (https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Cache-Control) and activating origin cache control on Cloudflare. As a result, we would serve stale the Asset (HIT) while we revalidate to your Origin, isn’t it the dream scenario?

For Argo, having tunnel isn’t enough, you need to have Tiered Caching enabled too, Traffic tab:

1 Like

Thanks a lot for your help,

about stale-while-revalidate that’s really dream come true :slight_smile: but its the first thing I tried and its doesnt work as I thought so, there is a long topic about it that got closed Does stale-while-revalidate work?

the worker I am working on to make the stale-while-revalidate work like dfabulich said or how fastly is doing it

about argo I guess your are on enterprise plan? mine look like:

Hum, I’m not expert of the self-serve plan, if you give me your zone name I could for you whether or not Tiered Caching is included in your Argo Tunnel subscription.

For the serve-while-revalidate, indeed our implementation of this is limited:

Cache an asset and serve the asset while it is being revalidated
Cache-Control: max-age=600, stale-while-revalidate=30

Indicates that it is fresh for 600 seconds, and it may continue to be served stale for up to an additional 30 seconds to parallel requests for the same resource while the initial synchronous revalidation is attempted.

The may means that during the revalidation (after the TTL) if 2 requests goes to us at the same time, the first one will be used to refresh the cache and the second will get a direct answer from STALE, so this doesn’t help in your case, I was mistaken… :frowning:

The cache Team is still working on the full implementation of the well used cache-control directives, bear with us!

really good to hear your are working on it, yes you may be using it according to rfc but like the topic above most would want to use it in other way I guess, I will work on my worker version for it, it’s really easy to achieve with worker,
my domain is would love to know if tiered caching is on in my case.

thanks a lot, good to see Cloudflare team on the forum.:+1:

Yep, I do confirm that tiered cache is activated on your domain. My curiosity, are you mimic-ing SWR with the cache API in workers?

its still not on production, I am not mimicking it according to rfc but for my simple use case I am doing like:

for example to support s-maxage=60, stale-while-revalidate=30

get response from the cache, test response age, between 60 to 90? return the cached response, and creating subrequest to the origin in the background and storing the response into cache again.(simplified) I will also use some buffering to make sure not flooding my origin on peak times

Cloudflare isn’t working on this. The team doesn’t understand the stale-while-revalidate directive, and they wrongly think they’re compliant because SWR is an optional cache header, so doing entirely the wrong thing is enough for them. It’s infuriating that they’re pushing people to their paid workers plan to get actual SWR support.

It appears that you know better than me what Cloudflare is actually working on :slight_smile:

And I never suggested to use workers to workaround our SWR implementation limitations. We’re working on getting a better product and I try not to set false expectation.

This topic was automatically closed after 30 days. New replies are no longer allowed.