I need to play with them. We'll see

Any possibility the changes might allow more concurrent socket connections or would it only be billing changes?

Hmm for more connections I think you'll need to shard and fan out

it's been almost two years since such a theoretical hibernation api was first floated here... i'm really looking forward to something landing.

is it a possible to make a DO keep a single Websocket connection open at all times and just forward fetch requests through the socket

Hey all, loving what Durable Objects can offer and am looking at implementing a case which has fairly similar requirements to the chat app example. The use case I have may need to require a very large number of active websocket connections though and I'm really curious as to the technical limitations of the combination of websockets and CF workers. Does anyone have an idea of what performance quirks there would be if say, 1000 people were using the CF chat room demo at once? And furthermore, would would be expected if that scaled to 10,000 people chatting in the same chat room, or 100,000?

If you have 1000+ people in a single chat room a single DO won't work you'd need to shard it

^^^^^^

Thanks! I'll look into sharding. I remember glancing over some docs regarding a 'waiting room' which seems relevant. OOI, is there a technical limit without sharding?

The technical limit is that a given DO instance runs on at most one thread, globally. https://developers.cloudflare.com/workers/learning/using-durable-objects/#error-durable-object-is-overloaded

Hey @conqr Yes, it's possible but if there are no requests for a little bit, the DO may be shutdown until a new request comes in so if you want to keep it always open you'd need some heartbeat

That 1000 is the unbound limit of subrequests, right? There's no hard limit on number of open ws connections, if I have extremely low message rates, and don't broadcast to everyone else, or is there?

subrequests has nothing to do with it, you just wont be able to connect 1000+ websockets to a single DO

👀 is there another documented limit somewhere? In the optimal case, with no bursts that fill up the message queue, is there a limit that prevents from passing another ws connection to the DO?

theres not any documented limit to the exact number because they dont set any hard limits on it specifically its just a single threaded object and cant have unlimited connections

Each one will use up some memory and you'll run out

Do durable objects support TLS sockets

yeah this and @Skye's response are understandable, I was just curious if there's a technical limit I wasn't aware of 🙏

@conqr No, it'll be available in the future but we don't support TLS sockets at the moment

Sorry, could you clarify this? I currently use a wss:// endpoint in my Worker-hosted application, are you talking about something else?

WSS sockets are supported, but TCP is not supported yet, and TLS sockets are just TCP sockets wrapped in TLS

Got it, thank you.

Ah thanks! The single-threaded aspect seems I/O factor makes total sense. Relating back to the chat app scenario, what would be an intelligent sharding strategy? As an FE dev, This is new grounds for me. OTOMH, it seems like timestamps or IP based factors could be an approach? And would all have to revolve around some arbitrary batch size / duration Auto-sharding totally seems like something that could be automated on Cloudflare's end 😉

Do you know when support might arrive?

Also is it a bad idea to use a DO as a cache

I would use KV as a cache over DO. DOs are single threaded which means they will only be able to respond to so many requests before dying, and DOs cannot store as much data per key and they are only existing in a single region. Or just use the cache api itself instead of any store but of course that doesnt guarantee your data to be there as long as you want so if you are trying to ensure you dont hit some service for a certain period of time KV would be the way to go imo.

@conqr Not really, the team is working on it but can't tell you when it's going to be ready

If data is cached in one region and can I invalidate / edit it from another region

To prevent it from returning stale data