@HardlyWorkin' can you explain what is `ctx.waitUntil` is for exactly in context of BetterKV?
@HardlyWorkin' can you explain what is
ctx.waitUntil is for exactly in context of BetterKV?
HBetterKV is able to serve a request from cache, while revalidating with KV. To allow you to respond as fast as possible, it uses
waitUntil
Bdoes
bKv.put revalidate values stored with the same key?HKind of? It puts the value into KV and the local cache, but that does not affect cache in another datacenter
HWhich is why the revalidation system is used
Bif i change the value of a key, how do i assure the revalidation happens everywhere?
HYou can't. It will happen eventually, but if you put a value in one datacenter, it can take ~60 seconds or so at a minimum to be visible globally
Bafter client requests or will it happen automatically?
HWith BetterKV, or without?
Bwith betterKV i think revalidation can happen throughout data centers cause you can just
cache.delete or maybe even cache.put does that for you (im testing that right now), but what about KV ?HWith BetterKV and no manual intervention, then it can take one request before it shows the new value(depending on whether or not the original is still in cache). For KV, it can be around a minute since the last access(or more, if you set the cacheTtl to be higher).
Ba minute is fine but how much longer can it take?
Bwell 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
B