Yeah DOs bill on wall time not CPU time. Polling would really be the only way to reduce it.

(unbound workers are also billed on wall time not CPU time. And bundled workers aren't billed for wall or CPU time just have limits on both)

Ah, I see, thank you

To answer my own question for others: - yes, a Worker requesting a socket response from a DO must follow the same protocol as an end client/original request, including a GET method, and "upgrade" header. Omit either of those, and you'll throw/crash. - itty-durable is being modified (transparently) to handle all that in a seamless manner.

Hi there, I'm having an issue with DurableObject execution performance that is causing some serious issues in a production environment, I've opened a support request but asking here incase there is a workaround.

Does anyone have experience establishing websockets between two durable objects? Is it even possible? When I add the upgrade header per the docs to have a DO act as a websocket client, using that same code that's working for normal requests, I get an error that seems to suggest the fetch request actually resulted in a request to reach the dummy url in my Request objects, not the DO as it normally would: "Fetch API cannot load: example.com". On the other side (the DO acting as a server) I don't see evidence that the upgrade socket request ever came through.

@dpeek can you DM me a link to your support request?

Hey when you run a worker that is bound to a DO, will that worker always run from within a datacenter that support durable objects? Or does that worker run anywhere and ALWAYS goes to another DC for calling a DO?

DOs are their own workers separate from the main worker script. So the main worker will run anywhere and the spawned DOs will be the closest data center to the execution creating an instance of the DO class. And whenever you call an existing DO instance it will look up where that instance was spawned and call it

thanks, is there any way you could pin them together so the worker and the DO could run very close together?

No you cannot. If the user who created the DO is the only one using it though it should be as close as possible

Got it, thanks. I'm trying to use WfP with DOs in a way that I can allow people run write their own DOs effectively, but since WfP can't actually define a DO my closest shot was having them run basically together so the fetch call was nearly no latency

I posted my question at kind of an odd hour, anyone have any ideas on websockets between two DOs?

Pages 2.0

It might be an idea to try and have a chat with @tanushree about your use case?

Would love to. @tanushree let me know how best to proceed

If I want to store 10 MB of data using DO's storage by splitting it into multiple values, that would count as 2560 read/write units?

If that’s how many you divide them into, yeah

Are durable object transactions isolated to the time they transaction was started? And are they serializable in that any changes to keys relevant to the tx will abort the tx on commit? Or is it just an atomicity tool?

Yeah, you could also use KV or R2

Yeah from a cost perspective using DO storage for "large" (10 MB isn't even that much tbh) feels pretty prohibiting

What's the speed of DO writing to R2? Since DO is charged for wall clock time.

Is there something known going on with Durable Objects / Alarms? Some of my DOs are not triggering their alarms.

Seems to be a very similar issue to the previous one, alarm is still set to the past and I cannot set a new time.

I can DM Durable Object ID / cf account id if anyone is around to take a look

One of the DO alarms was stuck for 7 hours, now it’s back. There might be other stuck ones I suppose, happy to help to debug this.

Thanks for the report, the team is debugging it now, don't think we need any more info yet

Im totally new to durable object and so I dont' know their black magic yet 😄 I was wondering whatever they would be a good use case for settings in an app to be sync across multiple device in a realtime manner ? I'm seeing more a realtime chat/game example but typically in my case I'm doing a webextension and webapp (be on the same device or not), I'd like to have those two thing synced in terms of settings. I believe a firebase realtime db would totally be capable of doing that. What about the durable object ?

Like having a websocket from each client connected to the DO to share changes? That sounds like a good use to me. Currently, an open WS keeps a DO "active" and thus we bill for it, so this could be more expensive than you'd like. There are changes coming to help there, though. No timeline or details yet 🙂

Yeah that's kinda the sad part. I wouldn't have a lot of activity but long period of listening