well i dont tihnk it matters if betterkv does invalidation by itself
well i dont tihnk it matters if betterkv does invalidation by itself
HBasically, with KV, you can receive a value from two places:
- KV Origin
- KV Cache
The KV origin should always have the latest value globally(barring network issues). So, if your KV.get hits the origin, great! You got a fresh value!
HYes, though note this happens after it first serves a request from cache(assuming it qualifies for revalidation).
Bso if i have a have a cacheTtl of like a year, betterkv will still invalidate after a single request?
HWell... Derp. I just realised, that's what it should do...
HBetterKV v2 was built to take advantage of KV v2, which also did background revalidation
HThus, it sets the KV
cacheTtl to a year.HBut, because KV v2 was set aside, now it will attempt to cache that stale value for a year, without revalidating...
HTheoretically, it is still correct, if you are using KV v2.
Bset aside? i thought the current version is betterkv v2
Bsince tere's a
old.ts in the directoryHYes. The current version of BetterKV is v2. But KV itself also had a v2
HWhich they rolled back due to some issues
Bhow recently?
HI have a message about it being rolled back in November, but I'm pretty sure it happened before then. Don't remember the exact date
Boh sht and they havent given any news about it ever since?
HNot anything that I have heard. AFAIK the KV team member that was working on it no longer works at CF
Blmao
Bvery unfortunate
HSo if you use BetterKV v2, then you probably want to override
kvCacheTtl to 60 insteadHSo that it can revalidate as fast as possible
Bwill that increase kv billable reads significantly?
HNo, because whether or not it is cached, a read from KV itself is always billed.
HI'll push a change to the defaults when I get time
Bcache api is not involved anymore or what? wasnt the point of the cache api to reduce kv reads ?
HI meant that, the logic that determines whether to read from KV is the same no matter the TTL you set for KV
HSo even if I set it to 60 seconds rather than a year, I would still have the same number of billable requests
Bthats for actual kv reads, but with cache api being with a high cache ttl, shouldnt it avoid kv reads to begin with?
HBy default it is set to 55 seconds, at least at the moment, if that is what you mean
HThough the revalidation logic means that it increases in likelihood the closer it gets to the limit
B50 *
HThis comment is wrong then... Oops
HGot some more stuff to clean up I guess
ADoes anyone to how to go about load testing workers? Is there a way to cap the amount of workers that runs so I can get a rough estimate of max req/s per worker?
Bi dont think there's a cap on that, the only bottleneck can be external I/O that you might be doing, like your database for example
AWe know the DB is fine, we're just shifting our traffic to be fronted by a worker to act as a router. It would be initially about ~60k req/sec? What I'm trying to figure out if every region should be able to handle the work evenly because I'd imagine not every colo has the same amount of servers.
B@HardlyWorkin' cant you just invalidate the cache globally by calling purge on a specific url ?
Bi think any kind of load should be fine
BBWorkers automatically scale onto thousands of Cloudflare global network servers around the world. There is no general limit to the number of requests per second Workers can handle.
VAre there any limits on how many route triggers can one worker have?
VAre you sure?
VSo basically if i would need to run 2k routes i would need to create a duplicated worker with a batch of other 1k routes? Then i would have 2 workers with different batches
VOr are routes tied to all workers on one zone?
Vdo you have experience in raising this limit? I see there is an option to " use Workers for Platforms or request an increase to this limit".
VYes i know but i am asking if anyone has experience with raising the limit. If anyone knows costs associated with raising this limit it would be greatly appreciated.
VWe are starting to implement edge SEO via workers on a pretty large webshop. And we dont want to trigger workers on each url because there are a lot of them. Any recommendations would be greatly appreciated.
KWorkers come from the same IPs as https://www.cloudflare.com/en-gb/ips/
KThe only way to really identify your Workers specifically is the
CF-Worker request header