fwiw, we’re currently heavy lambda users and paying for wall time vs cpu time is not a big consideration. lambda costs end up being a very small line item on our monthly bill, the biggest right now being lambda-triggering products like websocket api gateway. which of course DO could replace, and we’re much more curious about the DO/websocket worker pricing 🙂

what kind of latency are we talking? I haven't even been accepted to test DO, so I'm developing an entire CMS engine on KV (huge challenges and highly-unadvisable, but still fun challenge)... while I wait for the far more appropriate DO invite

At the time (several months) ago it ranged from 40ms added (on top of regular latency) to more extremes of 500ms+ though it usually bounced from around 50-150ms additional latency. At the time CF folks said it was partially due to very limited number of PoPs and likely the DO was running not near where my entry worker was. I've seen they have since added more PoPs, and they plan to include more before coming out of beta.

hmmm, yeah not great - hope they improve that!

They probably have already since then, and I'm confident they will continue to do so. 😎

In the initial release,

idFromName()

resulted in objects placed randomly around the world, resulting in poor latency, while

newUniqueId()

placed the object closer to you (with the caveat you mentioned that the overall number of pops supporting durable objects was still small). Since then, we've improved

idFromName()

considerably, so that it will also create objects close to you -- although there is still an unavoidable latency hit the very first time an object using

idFromName()

is created since we have to verify that the same object hasn't been created anywhere else in the world. I still recommend

newUniqueId()

whenever possible as it never needs to communicate around the world (unless the object is actually being used from multiple places around the world).

Thanks! Great to hear it has indeed improved. I'll keep a close eye for general availability and more PoPs.

I think that EWR was recently added as a do pop.

What is the expected latency when an object is 'close' i.e same POP. A single 1kb key read or write would be between x-x ms...?

Does the new

deleteAll()

storage method count as a single write, or does each individual key-value count as a write (w.r.t. billing)?

Interesting question. But we don't actually have billing worked out yet in general, so probably there's no agreed-upon answer yet.

my understanding of @User Q (please do correct me if I'm wrong) was about the latency of worker -> DO calls (hence why distance between PoPs matter); the actual call latency of a worker -> DO in the same PoP should be a few milliseconds or less on average

I didn't really have a question 🙂 Was just letting him know that we're interested in JS isolate isolate communication that performs well (sub 10ms, ideally even 1-5ms if achievable) regardless of whether that abstraction is worker -> DO, worker -> worker, or some other abstraction. Ultimately just want separate deployable JS isolates (environments). Right now we're abusing the existing design and instead concatenating scripts all together into one worker since the alternatives aren't (yet!) fast enough. That comes with issues; deployment cycle complexities, clashing assumptions, running "trusted-but-ideally-isolated-so-they-dont-abuse-private-apis" third party code (it's a weird use case, admittedly and trust that we're quite well aware of security and what we're doing has no risk)

e.g. our "gateway service" code has to be bundled into each of the microservice code, even though they are developed separately and deployed by very different people at very different cadences.

gotcha

are "nanoservices" (a la https://discord.com/channels/595317990191398933/773219443911819284/814167701353136128) basically what you want supported for your use case?

Yep, sorry if it wasn't clear that I was generally speaking showing interest in that feature or similar. 😄

nah probably my bad (just wanted to clarify), you're good 🙂

Clarity is good for sure. 🥳

Thanks @User, applogies for the clarity of the question, I was trying to acertain the likely storage I/O latency within a DO for a key read/write, assuming the original worker->DO call is negligible if in the same POP.

@ironman about clarity.....?

@User do you have a specific question?

@eidam | SuperSaaS sorry my kid had my phone

nice, already interested in durable objects, send regards

https://blog.cloudflare.com/cloudflare-waiting-room/ built on Workers for anyone interested

Hi all, I'm having an issue with this error in a storage.transaction:

Transaction failed due to conflict while processing a put() operation

I'm using DOs for storing analytics, and when two requests are (near) simultaneous, this error gets thrown. Has anyone had similar issues, or are there pointers to how I should make sure the transaction completes successfully?

At a simplified level, the way transactions work is that if two transactions have contention (one writes a key that the other wanted to write or read), one of them should go through while the others fails. We retry failed transactions, but if it's still contended, we throw an error reporting a conflict.

If your transaction is too large or takes too long, it may be difficult to achieve high throughput within a single DO instance; if it's a relatively occasional error though, I'd just retry the transaction.

Sorry about that, we'll be improving transactions over time to make them less likely to conflict and to auto-retry on conflicts. Note that if you need to work around the error you should be able to coordinate the various operations in your code as well to avoid the conflicts between the operations, although that can sometimes be tough to get right (which is why transactions are an option in the first place). Conflicts generally arise because two different transactions both try to read and then write the same key

It can vary , but as a rule of thumb storage reads will generally take single-digit milliseconds and writes will take tens of milliseconds.