I mean I wonder if there is any difference in cpu usage once function is running
I mean I wonder if there is any difference in cpu usage once function is running
Glike startup aside
MJS is likely to be faster for HTTP request processing. The benefit of Wasm is usually in heavy, off-request compute or where you want to use non-JS libraries/code
Gyeah, thats what im thinking as well, I just dont have numbers to prove it. I might end up doing some benchmarks myself
KThe WASM performance hits are usually when you’re doing any large copying of data between the WASM <-> JS boundary. Since the stringref proposal isn’t stabilised yet, strings are always copied rather than a reference being passed.
KUnless it’s a large workload, I doubt there’ll be differences other than a few milliseconds (if that)
Gyep, thats what I am thinking. I think the only place where one may see any difference is cost. I am not sure if I should expect it to be higher or lower for such case
Anyways, I will write up a benchmark someday to play around with it. Im just curious
Anyways, I will write up a benchmark someday to play around with it. Im just curious
TI just switched a short algorithm from JS to WASM. My worker was taking about 3.5ms before and after.
TI was worried that invoking the WASM runtime would have a big performance impact but I didn't see it.
Lhey folks! has someone implemented simple locks with kv? for implementing a synchronized monotonic counter
KKV is eventually consistent so I'm not too sure it fits your use-case
KWrites take some time to propagate, reads are cached, etc
Lhmm. good point.
D#durable-objects are much more suited for that - with KV the best you could do (not recommended) is to write a key on each request, and then list them 1000 at a time to count (again, not recommended, not scalable, just a way to abuse KV into what you want)
Lcool! will look into this
Lthanks @Dani Foldi @kian ! 
Lhmm are there any replication guarantees? like writes are replicated in the same order?
Llike if i find the key i’m looking for, every key i’ve written before will appear in a kv prefix scan
HThere is not
IAre you thinking of saving each sequence to a KV key?
IOk, so a read-heavy kind of design is perfect for KV (as long as the value is <25MiB, which seems the case here).
IYou'd need to be ok with a short propagation delay once the sequence updates.
IOk, then a single store makes sense.
IA Worker is better the smaller it is, even though the script is limited to 10MB so it would be fine, keeping it under 1MB would be ideal.
IDo note you are limited to 50 (or 1000 in Unbound) fetches per request, so 7500 wouldn't even work.
IA single KV key would be the way I'd go, personally.
IR2 might work, too, but it's slower on average and it requires more processing. D1 is not yet GA, but also costs per data processed.
IDOs are not worth it here.
MHi all 
does KV have something like Redis LRANGE?
does KV have something like Redis LRANGE?Mactually DO's look amazing for this use case. will give that a try
Lbut would fetching specific keys force replication?
UWrites are replicated when you write and its just a last writer wins and if there happens to be a mismatch between the data sometimes the read can push through a replication fix where it chooses one. But you are also only supposed to write once per second to a specific key so if your use case involves higher write throughput than that you probably should not be using KV.
TCould someone confirm that the dashboard numbers (operations) are for the last 24 hours but the limits are counted from 0:00 UTC?
Thanks
Thanks
TAnd if true, do we have anyway to know what have been used during the last period(s) / 0:00 - 23:59 UTC?
MIs there any way to bulk fetch KV values in a single request from a worker?
CYou should be able to use the GraphQL API to get that data
Li'm actually only writing once per key, but every now and then I'll need to write N things and a summary of what those N things are, like this:
Lwhat I still need to try is if the following read pattern will force replication of all the entries in the summary:
LIn the docs I also saw this:
but i'm not sure how this would look like in code?
One pattern is to send all of your writes for a given KV key through a corresponding instance of a Durable Object
but i'm not sure how this would look like in code?
Lyes
Limmutable as well
Lso there may be subsequent rquests to
summary:1 but it will never change once its writtenL(same for
entry:1, 2, 3, etc)Lcool!
Lwill give this a shot soon
