My goal is to win the bet & get Sid (TL for pages) to shave his head bald if we hit certain performa
My goal is to win the bet & get Sid (TL for pages) to shave his head bald if we hit certain performance milestones
B(We have a grafana panel tracking that)
JIf this happens, Sid is obligated to come to our next meetup bald
HVery good point. Skye is correct that performance is not the #1 priority for BetterKV, pricing is, but I do also definitely see your point. I’ll probably add your suggestions as a performance mode that people can enable
BIt's also net a cost savings. Would you be open to making it the default & the user needing to turn it off? Even if you don't want to do the probabilistic piece, can you shorten the cacheTTL so that it's under what you give KV? Otherwise, BetterKV is not really different than cache+R2.
WI can't wait for this
HQq, what’s your username on Discord, so I can credit you for the changes?
Bvlovich
BOh that's my github username
Bbeelzabub#0369 on Discord
HWait
HNo, I meant GH
HI guess I’m just brain-tired from the heat…
H
BBut yeah, being more likely to refreshing the value as you approach the expriy end date is a significant cost saving measure. Counter-intuitive but true. It's how KV has to operate under the hood for similar reasons. We technically use a bounded exponentially increasing algorithm where after 5s there's an infinitesimaly small probability of a refresh that doubles with every passing second up to 100% at something like 45s or 50s at which point every read has a 100% probability of causing a background refresh. That way only a small subset of requests end up triggering a refresh while the rest just always serve from the cache without any stampeding herd. We have other tricks we're layering in as well, but they're not available externally yet.
ZHow old is this writeup? I did not even know that putting cache in front of KV was a thing at some point, and from the time I started using (~2 years now), I always assumed KV is parallel to Cache. In other words, since KV is already at the edge, what's the point of cache in front of a cache?
UTo reduce billing since KV cache hits are still billed but the cache api is free
DNow that you have exposed the cache status of reads, this becomes a lot easier to implement - previously when I thought about a probabilistic update, using the time the read took as an indicator for hit/miss was rather messy, so thanks for implementing 
D(one small issue I noticed with the docs PR, the ToC seems to cut off at some point)
BThe latter
エHi.
Is there any problem with publishing Cloudflare kv id, preview_id on github?
I have defined id, preview_id in wrangler.toml like this, is it ok to upload it as is where it can be seen by unspecified people? Or should I put them in .dev.vars?
Is there any problem with publishing Cloudflare kv id, preview_id on github?
I have defined id, preview_id in wrangler.toml like this, is it ok to upload it as is where it can be seen by unspecified people? Or should I put them in .dev.vars?
ZEverything in
wrangler.toml@zegevlier Thank you.
Is it OK to write directly in wrangler.toml and make it public for things like api key provided by cloudflare, not just kv?
I'm curious because GCP and AWS keep things like api_key secret.
Is it OK to write directly in wrangler.toml and make it public for things like api key provided by cloudflare, not just kv?
I'm curious because GCP and AWS keep things like api_key secret.
ZNo. API keys should never be made public. You should not be storing these in your
wrangler.toml
エThank you very much.
I wasn't sure how to tell which items should be secret, but I think your advice helped me understand a little better.
I checked the cloudflare dashboard and the api tokens clearly says "Protect this key like a password!" to keep it secret.
I'll try to keep this kind of warning secret, but if there is anything else I should be aware of, could you please let me know?
I wasn't sure how to tell which items should be secret, but I think your advice helped me understand a little better.
I checked the cloudflare dashboard and the api tokens clearly says "Protect this key like a password!" to keep it secret.
I'll try to keep this kind of warning secret, but if there is anything else I should be aware of, could you please let me know?
ZIn general (this might not always be true, but it's usually a good rule of thumb. As far as I know it always holds for Cloudflare stuff), IDs are safe to share, keys and secrets are not.
エThank you again and again for your kindness. I understand.
JGuys there is issue in kVs
Jit crashed my whole server almost 5 times today
JFixed now
EHi @bhadoo, can you share with me your affected account ID?
EThank you, I am looking
Ei see an increase in errors around that time but it should be back to normal now. Please do let me know if you see this again
EChecking
EThis has been escalated
EThe right teams are looking at it now
ZIs there a disconnect in the docs between:
https://developers.cloudflare.com/workers/runtime-apis/kv/#cache-ttl "It is not recommended if your data is updated often and you need to see updates shortly after they are written, because writes that happen from other global network locations will not be visible until the cached value expires."
vs
The new decoupled arch as described in https://blog.cloudflare.com/faster-workers-kv-architecture/
(I would like to be sure that increasing the cacheTTL value will not backfire on me.)
https://developers.cloudflare.com/workers/runtime-apis/kv/#cache-ttl "It is not recommended if your data is updated often and you need to see updates shortly after they are written, because writes that happen from other global network locations will not be visible until the cached value expires."
vs
The new decoupled arch as described in https://blog.cloudflare.com/faster-workers-kv-architecture/
(I would like to be sure that increasing the cacheTTL value will not backfire on me.)