Caching to avoid zone hits
Hello, Good morning : )
I want to ask that if it is possible that we can cache the response of a route in the cloudflare so that it does not hit the worker script for the response and directly uses the cached one ?
The response of the url updates on every sunday, and I am planning to implement SSR for it but I am unaable to figure out how do I cache it so that it does not invoke my worker everytime for the same response generation.
19 Replies
Worker responses cannot be cached. Workers themselves can utilize the cache API, but requests to them will still be billed
Workers run in front of the Cloudflare Cache layer. This means it's not possible to avoid invoking a Worker by using the Cache.
If you want to cache things between Worker invocations, you can use the Cache API to store and retrieve data from the Cloudflare Cache (which is local per colocation).
For global data/cache storage, you may be interested in Workers KV instead.
Any better option which I can implement to reduce the billing cost ?
Rebuild on Sundays, and make the page entirely static?
Can I cache R2, KV, D1 data into worker to avoid hits on them ?
The build process doesn't implicitly have access to R2, KV, D1, etc., no. But you can give it access via the API
I mean,
When the request comes to the worker first time for that data, can i fetch it and cache it in the worker for maybe 7 days and use it from the cache directly until it gets updated or removed?
(I am using caching first time in worker)
Not directly. The Worker would always be invoked, with that architecture
Hm, yes
I am okay if worker invokes but not the R2, KV, D1 invokes every time for every single request.
If that is possible via caching..
What if you do the computation, and then use R2/KV as a cache? You would still have a single read, but it is better than hitting all of them on every request?
Meaning?
Do what you were saying above:
When the request comes to the worker first time for that data, can i fetch itBut then to cache it, push the processed data into R2/KV. It wouldn't completely remove the number of reads you do, but it would reduce it, since it is now a single read performed, rather than many
Okaaaay..
But why I should cache it in the R2/Kv when I can cache it directly in the worker global cache?
Caching via the R2/KV will require me to make read call on db on every request, but if I use global cache it will skip that db read call.
Am I missing some important point on which you have pointed me to use R2/KV ?
Can you please guide me the correct direction: )
Because the Cache API isn't "global" in that sense. It is available everywhere, true, but if I send a request to your service, I'm served from the nearest datacenter, and the data is cached there.
The cached value in SFO is not available to a user connecting via ARN.
Also, the Cache provides no guarantee about how long something stays in cache. Even if you set a TTL of 7 days, it may be evicted sooner because of low capacity/low request volume
Oh, okay so the cache is not that consistent.
Sorry, but can you please tell me the full form of
1. SFO
2. ARN
?
What do you suggest as the best approach here ?
After your teaching, I am thinking jt like
First time recieved on datacenter do the calculation and stuff, store it in KV and also cache it for the data center.
Next time when recieved, check cache. If it is a hit then serve else check KV,if hit then serve else redo operations save to kv, cache it and serve it.
I was just referring to two different datacenter locations(San Francisco and Stockholm). This could be any other pair of datacenters
Your way would work, I would think?
Okay, Great.
I have few more questions not related to the current thread topic but related to worker.
Can I ask them directly here ?
I would probably create a separate thread, just to keep each on topic?
Okay, no problem : )
Thank you.