Thanks! In my case since these sub-durable objects will have to do mostly CPU work, it should then be fine 🤔

I have facing this issue

I'm using JavaScript not TypeScript but I do it lazily: https://medium.com/cloudflare-durable-objects-design-patterns/lazy-hydration-cab27e7c70b5

I was under the impression that even if multiple instances share a blade, each instance gets access to a full 128MB. I'm guessing they can use swap and eject inactive instances to achieve this... but these are all assumptions. It would be nice to know for sure.

it's documented that DO instances may share memory, nothing about that has changed https://developers.cloudflare.com/workers/platform/pricing/#durable-objects https://developers.cloudflare.com/workers/learning/using-durable-objects/#in-memory-state-in-a-durable-object

regarding likelihood of at least 1 instance sharing memory in a given location... it's basically the birthday paradox, i.e. more likely than you might think

Any plans to update this/billing, since because of duration billing, you are in effect paying for memory that you can't use?

no different from normal workers in that respect

That question could apply to normal Workers too, since you may write a Worker expecting to be able to use the full 128 MB of memory, and then run out.

afaik those memory / duration increments were done to make ease of comparison to other services

Especially if you are running a lot of DOs/Workers in the same place, your effective memory goes down pretty far

How do you do staging / production with durable objects? Do you have to have two classes e.g. ExampleClassStaging & ExampleClassProduction?

But what happens when you run out, is the DO restarted without sharing? How to manage this when you need the memory?

IIRC, the DO is restarted. If you need the memory, then maybe use a Queue?

Or use a

blockConcurrencyWhile

Neither of those are really ideal, but those are what are available at the moment

blockConcurrency wouldnt really do anything to help with memory, and I'm pretty sure queues also share memory with other requests to that same worker on the same server 🤷

Well,

blockConcurrencyWhile

would at least prevent new events being delivered, (mostly) guaranteeing that each event gets 128 MB of memory.

I guess maybe you could make sure the queue is a stand alone worker only for the queue and concurrency 1 and that might work. And blockConcurrency would only block for the same object but the problem is multiple objects share the memory

Oh right...

I don't see how to pull this off for persistent websockets connecting several clients, if it restarts and is able to get the memory, I can live with that, not sure, if it keeps restarting indefinitely...

@ckoeninger would it be possible to have a way to define "this Worker/DO should always be run it in its own isolate" for applications that are compute/memory heavy? Since while DO/Workers can have a theoretical maximum of 128 MB of memory, in practice, they may have much less(accounting for multiple requests/DO instances in the same memory space). This shouldn't be a default(maybe a wrangler.toml option), but it would be nice to know that you don't have to design apps to deal with extremely diminished memory space.

In my case, if move to micro-DOs most time / effort would be on serialisation and communication between them and I guess restoring them, because I guess they would get evicted more frequently also...

This is a general problem I've had before - e.g. when working with a modal editor where each mode is an object that exists for the lifetime of the editor, a bunch of each mode's state will be nullable depending on whether the mode is active. The pattern I'm trying to move toward is having the nullable state wrapped in a separate object which is constructed when it's needed with non-nullable properties. So in your durable object constructor, you could

blockConcurrencyWhile

to fetch some data, then create an object with the non-null result and store that object. Then your

fetch

handler can delegate calls to that object, doing the null check in a single place. This is a bit of ceremony, and might not be worth it. Sometimes I just end up with

!

everywhere, or a guard clause at the top of every method which asserts that the state is valid. But if your problem looks like a state machine, and there are a lot of different state properties which are null/valid together, then it can pay to model the states of the machine separately, rather than having "one big class" with everything in it. I've only done this properly once, but I ended up writing the entire "business logic" of a DO in a separate class which was completely pure. The DO class then just instantiates and pokes the business logic class. It was great for testing - no need to set up websockets etc., I just wrote pure tests against the business object.

Hi quick question, I am trying to connect to using websockets locally using

wrangler dev

but it fails to establish a connection. Doing it on a deployed workers url works fine. Does Wrangler not support websockets?

I can confirm websockets do work with Wrangler running locally. In the client-side portion of your app are you changing the address(probably should be 127.0.0.1 or localhost), port (8787 or whatever you set it to with --port), and proto(ws:// instead of wss://) for local?

It might be friendlier for a DO to specify the amount of memory required. But I'm guessing either option will imply billing changes. Although I understand CF view point, but by allowing us to specify that a DO requires 1MB or 10MB or 128MB, would allow all kinds of optimisations on isolates and minimise unused memory, beyond the current "shared model". For instance by specifying 1MB, they know an isolate can handle up to 100+ of that DO, but 10MB only 10+ and 128MB only one. Of course you could have 50 1MB DOs and 5 10MB DOs... While giving us the flexibility to have the perfect sized DOs without this issues that we can't manage.

what is the recommended way to nesting durable objects?

If I recall correctly, the issue with this is that there's no easy way for workerd to report the accurate memory usage of something in the isolate until after it's completed, and it only really knows you're OOM when you actually hit the limit