Yikes, that's really disappointing.
Yikes, that's really disappointing. Thanks for the info.
I'm coming to the realisation that CF is only really beneficial for very high traffic sites -- I wonder if all CDNs are as quick to evict cache entries.
27 Replies
is CF specifically that quick to evict? I don't think they are, could vary a bit with the colocation center you are connecting to though/might be seeing the result of a multi-colo pop where each colo has different cache
this asset has only got a handful of requests over the last 24 hours
but still firmly in cache
that's what, 18 hours cache age and it didn't even have requests for the last ~6 hours
no tiered caching or anything enabled on that hostname
I wonder if it's less likey to evict js or perhaps the file size is v. small?
We cache a bunch of API requests to origin with the Cache API and often see a miss if left for 10mins or so
I wonder if it's less likey to evict js or perhaps the file size is v. small?Maybe, the only bit that I know was clarified to us was that - Cache is based on Access Frequency - Cache does not care about zone plan It depends a bit too on how exactly you are measuring it Cache API is local colo only, some PoPs like EWR are actually like ~5 colos in one, all with their own cache, and you have no specific affinity to one besides for keepalive
Yeah this is why I want to get tiered caching, as it seems we don't have enough traffic to prime all the individual colo caches.
tbh I don't have great visibility into the cache because the cache keys we use are pretty obfusicated (POST body hashes) similar to this https://developers.cloudflare.com/workers/examples/cache-post-request/
I'm not even sure Cache API entries are shown in the cache performance graph
the one in the dashboard "Cache Analytics" excludes them
The caching overview filters requests to only show ones made by eyeballs/actual users, via the "requestSource"
There's edgeWorkerFetch and edgeWorkerCacheAPI which workers fall under
could view them via graphql still
ah nice, will take a look thanks
yea there's a whole bunch of types
and again only the cache analytics shows "eyeball"
{
"count": 25303,
"dimensions": {
"cacheStatus": "hit",
"requestSource": "edgeWorkerCacheAPI"
}
vs other types (miss/expired/stale) would probably be what you'd be after
cool, I'm going to try and shove that into a graph to see if the cache really is as ineffective for us as I think it is 👍
weirdly, I don't see any
edgeWorkerCacheAPI sources in my zone 🤔
plenty of edgeWorkerFetch though -- even though we don't use the fetch cachingthat'd appear if you are fetching out at all though, caching or not
hmm and you're using cache api on a worker attached to that zone? Pages Functions would always be executing in the context of the pages.dev, for example
ah ok, I suppose it still potentially caches responaes if the origin headers allow it -- regardless of passing cf cache ttl
fetch('foo', { cf: { cacheTtl: 5 } })?those are just overrides yea, you still go through the normal cdn/cache rules/etc
This option forces Cloudflare to cache the response for this request, regardless of what headers are seen on the response. This is equivalent to setting two Page Rules: Edge Cache TTL and Cache Level (to Cache Everything). The value must be zero or a positive number. A value of 0 indicates that the cache asset expires immediately. This option applies to GET and HEAD request methods only.https://developers.cloudflare.com/workers/runtime-apis/request/#the-cf-property-requestinitcfproperties
our "zone" is configured as a custom domain on the worker in question
so I'm assuming that means analytics would come under our zone, rathert than pages .dev
(we are using CF Pages)
no, if it's a Pages project, you don't have a worker, you have a function, and all invocations of the Pages Function would belong to the pages.dev zone hidden in your account
Oh really. Can I view the pages.dev zone? (although last I read that didn't support caching)
Worker: If it's ran via your workers.dev, it's yourworkersubdomain.workers.dev zone Worker: If it's ran via route or custom domain, the request belongs to that zone Function: If it's a Pages Function, it's always the pages.dev zone even if called via a Custom Domain Worker: If it's something that runs without an http request, like crons, queues, etc, it's your workers.dev zonepotentially, 1sec. and no, workers.dev doesn't support cache apibut the pages.dev does If you go to Manage Account -> Audit Log, filter by your pages.dev, you should be able to find an event like a certificate renewal which leaks your zone_id, and then you could search for that in graphql
they're just hidden zones in your account, as far as I know fully functional in all the apis (you can mess with them a fair bit, but I would recommend not doing too much to not upset the pages team lol or they'll lock them down more, reading analytics/settings should be completely fine though)
might be an easier way but this is the way i know lol
you'll be restricted in the graphql datasets you can use though since they're free zones
haha, ok yeah, found the zone which the API recognises, but doesn't let me read
httpRequestsAdaptive or httpRequestsAdaptiveGroups 😔
I think I'll ping enterprise support and see if they've got any suggestions on getting visibility into cache usage -- thanks for your helpIs this still valid? I had a talk with a CF eng recently, and it seems they changed this behavior last month. I tested it with a few colos today and got a
HIT immediately after the first MISS, all from different Colo IDs.without tiered caching? My understanding is still yes, they haven't changed the docs at all either (ex: cache api still mentions originating data center), unless they've done something special with MCPs
Yes, it was MCP-related. Thank you! I've been trying to remember that name. 😅
It seems Cache API now shares its storage between all DCs in a region. Not as good as Tiered Cache, but definitely much better than before.
that would be nice if true, I don't have any websites with a lot of cached traffic that don't already have tiered caching on though lol, and on those ones I don't see cache miss changing
would be interesting if someone had a website without tiered caching and a lot of requests, if their cache miss changed at all
it does look suspiciously like it was changed, same age and such even from different colo ids in the same pop, will ask if anyone knows anything
Yep. This Worker route is using Cache API only. I wish they documented or at least announced these changes somewhere, at least here on Discord. 😅 That's valuable information.
times like these I wish I could go back in time and create a monitor to see the performance difference lol
I have something monitoring a cached endpoint but it's behind generic tiered cache with middle tier so pretty useless for monitoring this, already had 2 levels