High number of requests to origin for the same resource

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.