Not really what exactly are you doing that you need other profiles other than the one sending the message?

I just need the profile for the one person who send it

And from what I understand you also pay per Dynamic Object. So costs will get very high of you have a seperate namespace per profile/user

So you just create an object per user and you can fetch only one user in that DO.

You pay for duration an object is handling a request so I guess it is in theory possible you have a bit more duration than if you are doing many fetch requests in parallel on a single DO but the duration costs are going to be very low if you save the profile info in the DO and only fetch if you want to update their profile info because the DO storage is fast

Ahh okay that makes more sense. Thank you so much!

I have a DO that only does get/puts to storage had 35.1m requests average duration of 17ms per requests which is about 74,720.52 GB-sec which is like $1 in duration charges (assuming you exclude free tier) so not that much 🤷

Nice sounds good

ok thanks - saves me time, I won't try to put any retry in for this one

Any chance the graphql analytics api will show GB-s duration for durable-objects like it does with workers & pages functions?

It should, maybe I'm misunderstanding?

Right now you can only get wall time in microseconds, would be nice if I could just get the raw GB-s instead of having to convert microseconds -> GB-s

Ohhh the conversion

What's the GB-s field called in the others?

duration

found again this morning:

2023-01-19 14:27:19Z

Error: Durable Object namespace binding cannot communicate with other nodes.

looking

same machine, should be disabled now, trying to make sure no one re-enables it

anyone here using the workaround to query D1 from their durable objects? if so, the beta build of wrangler might be interesting for you:

npm install -D wrangler@beta

- patch notes: https://github.com/cloudflare/wrangler2/pull/2561

This is going out shortly

Thank you 🙏

Hi guys, I'm once again seeking help here to better understand how the platform works: I'm using Durable Objects with WebSocket. Only one single client is connected to the DO at a time, but sends __lots__ of events in real time. These events require some data operation to be executed, and the order of does matter. What I would expect, reading the Transactional Storage API rules, the

put

"write buffer behavior" notice in the docs, and the

durable-objects-easy-fast-correct-choose-three/

blog post, is that if the in message handler function I have some

await this.state.storage.get(...)

at the beginning and at the end some

await this.state.storage.put(...)

at the end of the function, it will essentially behave as a FIFO queue for the messages, waiting for the whole message processing to complete, then continuing to the next one. Am I assuming this wrong and that doesn't work as I expect using WebSocket messages?

Also I would assume that until the WebSocket connection is alive, the DO will be active: being active, I would expect that if I do something like this:

js
webSocket.addEventListener("message", async msg => {
if (!this.randomObject) {
   this.randomObject = new RandomObject(fileName, this.env);
}
})

the

new RandomObject(...)

part would run only on the first message received, then it would store the variable in the active DO memory (not storage) and would never be called again. While what I'm getting is that the actual "sync" of this variable is not instantaneous. Is it possible that the DO runs some functions in parallel and not as it was a single threaded process?

So, while the Durable Object is single-threaded, it still uses the standard JS concurrency model(as in, when a handler yields, maybe due to an async op, another event can be handled). To prevent this, you can use state.blockConcurrencyWhile

So the whole magic behind the blog post “easy-fast-correct” does not really solve all the concurrency-related storage issues? 🥲

We are looking over it right now to see what the actual expected result is but from my testing (which may be flawed) it seems like its actually impossible to be processing 2 requests at the same time.

By doing some tests, I've figured it out that if I don't have external

fetch

calls in between storages operation, then the code executes in the order I expect. While If I have even just one external call, then it breaks (__my__) expectation of how the storage api would work. I underlined "my", because again, I would expect something form what I've read, but apparently I have misunderstood what's in the documentation/blog posts. And considering the V8 concurrency model, as explained by HardAtWork in his answer, this is 100% how "normal" js would work. But it's not how I would expect it to work 😂 If you need the code for my tests, I can easily provide the DOs I've made!

I actually got it my tests arent flawed my browser just is for some reason my browser wont let me call the same url concurrently so it seemed like concurrency wasnt possible in DOs.

Oh, I'm using either websockets to the DO, or one api call to a worker that does X calls to the DO

As I had found a difference in how fetch and websockets events are handled