Sthanks @Isaac McFadyen
IAlso probably good to keep in mind that List can see metadata so if your data is small enough it might be worth putting into metadata so you don't need a Get for each one: https://developers.cloudflare.com/kv/api/list-keys/#optimizing-storage-with-metadata-for-list-operations
Syes read that but I read a blog post (old) that was stating GET was around 20-30ms and list 200ms (x10) so I got scared
IHmmm possible it's not cached actually (get is cached). I assumed it was but maybe not?
IDocs don't say... if anyone else can confirm/deny then it might be a good docs addition.
Sthat'd be awesome to have real value here, and answer from CF yes!
LThat blog post is fairly old. Cold read latency for lists is lower than 10x GET latency at P99, but absolute latency values for you depend on your location as cold reads come from central stores, and also depend on how many keys you requested.
IIs List cached or no?
LIt is. Each listing page is cached iirc.
Scool thanks guys!
SIs there an ongoing incident with KV? Getting 500s from workers->KV
SIs Cloudflare KV a good option for low-latency needs, should I use it in Next.js and NestJS? We need to add it directly; we can't use the KV because it's causing latency. Is there any way to avoid this?
L
Hi, I have a question about Metrics and how to interpret them. OI the image, there is read latency of our KV store. Is this correct interpretation?- P99 390ms: means that 99% of read operations are done under 390ms
- P50 18ms: means that 50% of read operations are done under 18ms
UAnyone seeing latency issues in KV?
Cnot really
Cthe chart to the right of that is more interesting, how many cold reads do you have? Are you setting cacheTtl higher where you can/have a lot of infrequent keys?
UThanks @Chaika I'm not using cacheTtl, I will set it now and see.
this is my read status chart
this is my read status chart
Cgood amount of cold reads. KV only has two actual backing stores/locations, one us and one in the eu, it's then cached everywhere else. Cold reads are expensive
Raising cacheTtl at the cost of consistency can help if it fits your use, or in general aiming to hit a few frequent keys rather then many infrequent
Raising cacheTtl at the cost of consistency can help if it fits your use, or in general aiming to hit a few frequent keys rather then many infrequent
YIf you don't need workers and want to use KV, you can only use HTTP, right? The interface request limit is too low.
HYes. KV is really meant to be used with Workers. In the event you don’t want your program logic on Workers, I would still recommend using a Worker to do the actual reads/writes against KV, as it should be a lot more performant than using the default HTTP API
YBut it's really difficult for workers to restrict the development language
HWhat do you mean?
AIs this because of the connection overhead of using the HTTP API? And is it mitigated for writes if you’re using bulk writes?
TYes, it's actually because the HTTP API includes both control plane operations (create resources in Cloudflare) and data plane operations (write, read on KV for example). We're working on removing the API rate limits entirely because KV itself does not need to be rate limited
TSo today, if you use bulk operations, you can definitely do more operations against your KV namespace than with individual operations
1Is the removal of the API rate limit just for the KV endpoints? Or is there a more general discussion around removing that limit altogether
Psome people put the Cache API in front of KV to reduce read costs, and it's still very fast (not sure if faster tho)
Puse whatever works
Puse kv as the persistent backend that the cache api will pull from
TKV is the persistent source of truth for data for many developers. What are you using as your persistent store in your case?
TIf you have small data that can fit in Secrets or Workers Environment Variables that is static (changes to secrets and env vars require new deployments), then yes, that's a good solution
AWe are trying to decide if to adopt KV. Here is our scenario:
- We're using their KV store alongside Cloudflare Workers to serve as a cache for some of our frequently queried postgres queries.
- We're hitting the cache, directly from the browser by querying a worker's API endpoint
- The average payload size is 250kb, but it's taking 300-400ms to respond
Ais that expected performance? Not based on anything, I would have thought we'd get even faster performance
Aor is it possible we have misconfigured something
P#hyperdrive better suited for this. tho 300-400ms for kv seems long
THyperdrive is a good fit indeed @Alex Izydorczyk . But both Hyperdrive and Workers KV use the same caching layer. The difference is that Workers KV is persistent storage. If you write something to KV and access after it has been removed from cache (based on the cacheTtl parameter), you will be getting the value from KV's central stores https://developers.cloudflare.com/kv/concepts/how-kv-works/
ANot to throw my own engineer under the bus, but he says " Hyperdrive is just a connection pooler with a very light caching layer. It makes connecting to postgres quick yes, but not a true caching layer like KV." -- it sounds like we have some fundamental misunderstanding of the product difference?
1Should I be seeing latency this high, even with mostly cold reads?
YDoes the webrtc of CALL have to follow the SFU protocol? Data to CloudFlare servers, does everyone's connection consume data?
Pwhy is the write in batch function only available via rest API and not via the worker API? does not make sense.
Whow to import
i am importing with
but got
anyone help me?
envcloudflare:workers?i am importing with
import { env } from "cloudflare:workers";but got
anyone help me?
XProbably add
cloudflare:workers to Webpack externals?