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)