we don’t implement a way for list to only return keys yet unfortunately

thanks, so if/when there is we could get a performance gain, when we just need the keys, right?

I wouldn’t expect the difference to be very big unless you have lots of keys with very large values

Hi CF DO team 🙂 As a hobby project (hopefully at some point commercial) I'm building a game in which multiple browsers share the same room and one of the connected users is the authority. The question is: how many websockets can a durable object have open simultaneously? From what I understand it's a single thread in some magic (V8) VM, should I be thinking tens, hundreds, thousands? The messages will be small and there is little processing done by the DO (it just passes or broadcasts it), I guess at most 10 messages being broadcast per second. Just trying to figure out of CFW+DO is the right solution here 🙂 (I guess I'll still have to wait for pricing details as this may get expensive fast)

@User I think you'll have to do some experiments there, we don't have any numbers for that yet (that I know of), and what matters most is exactly how much work the DO has to do per message so a max will vary between apps

Ok :) thank you!

I'd encourage anyone using typescript to kick the tires on https://github.com/cloudflare/workers-types/pull/112

@User best estimate I've got so far is to divide a second by how many milliseconds each message takes to process, so if each message takes 2ms then it would be 1000/2 = 500 messages/second. But that doesn't account for cases where messages take longer than average (our use case has some processing involved, which changes from message-to-message) or how much processing is required to loop through the connections to broadcast it out. I'm currently working on getting a better sense of that in our workers, but it's a tricky thing to answer.

What I could use is any advice on profiling individual messages, besides just logging the time diff from received to processed (if there's a better way). We have occasional outliers I'm trying to track down, but visibility into workers using websockets is rough around the edges atm.

That's a very helpful way of looking at it, thank you. I'm thinking the uncertainty, locked-in-ness, and not year clear pricing model makes DO a poor choice at this point. Seeing as it's mostly a message passing server anyway, probably something simple in Go or Elixir/Phoenix with a more traditional host will do the trick. Thank you again

Maybe a DO is still useful to keep any state per room 🤔, back to the drawing board 🙂

I've really enjoyed using DO for that overall, and rewrote a Go server in it for the auto-scaling. But the unknown pricing is a bit of a worry, and I fear we'll be hitting performance limits we can't easily get past with JavaScript. Maybe one day we can write DO workers in WASM which might help us eke out that extra bit of performance.

Another wish would be WebRTC support. Lots of our data is ephemeral and doesn't need TCP's reliability guarantees, but some does, which could lead to congestion issues with DO.

I have done the exact opposite, rewriting/moving stuff towards a Go server. Mostly for reasons not related to CFW though, but customers who are wary of anything hosted/run by an American company (Cloudflare) - however unreasonable that is.. What is your application if I may ask? I am building a quiz-style game where you use your phone as a controller/gamepad (with a shared TV screen). Those games can easily be designed to allow for pretty high latency (and they should be as people will play it over screenshare in Zoom/Discord). In the past I've used WebRTC data channels for p2p multiplayer in a hobby project first person exploration game

At the time there were no WebRTC implementations outside of the browser whatsoever (this was +6 years ago), so I couldn't use webrtc to talk to a server, all the server did was introduce clients. If DO will ever support WebRTC data channels I'll be very happy - but I'm not counting on it as it's such a fringe usecase 🙂

It's a VR live streaming platform we're trying to build. Go does make the most sense with the high quality Pion WebRTC library, but the appeal of a DO-based solution is spinning up individual workers per-stream so they never affect each other's performance, and an edge network of relays for scale. We now have reference implementations in both, but are undecided on the way to go. DO simplifies a lot of things, but we might be hitting the upper limits since we want to push upwards of a few hundred messages per second (depending on how many actors there are in a given show).

Interesting! My gut feeling tells me you will need unreliable updates for fire-and-forget type messages (e.g. user location+rotation) and the delivery, orderedness and retry guarantees will hurt there (and will back up the pipe so to speak if connection is lost for a little bit) - but of course you have given that a lot more thought than me! The reliability and scalability is also the main reason for me to consider DO for this.. Less chance of my service dying and the game being unplayable.

Thinking about it a bit more.. I guess you could shard the connections across multiple DOs? Where there is one DO that contains the actual state, and multiple DOs that maintain a connection to this state DO and to many end-user clients. Of course that stateful DO will still have to be able to manage it, but at least it won't have to loop over every listener to broadcast things. In your case of ephemeral/rapid fire updates you could also debounce the upstream messages in the shards.

Exactly the challenge with positional data (and audio). Also considering using two connections so we can separate out the state management, since that does a tiny bit of extra processing but only on certain messages but waiting to benchmark a bit more before deciding. Relays were super easy to setup at least so as we add new viewers we can set limits per DO, but I need that central DO to be nice and lean...

sorry is DOs unbound a thing yet/sometime? (so a websocket connection does not terminate once it eats up its [very little] cpu quota?)

Does the DO terminate it with a specific code when a WS has hit the CPU quota?

Wherein I learned that DOs are neither bundled nor unbound: https://discord.com/channels/595317990191398933/773219443911819284/887699442122260540

the request part is confusing, soa websocket msg?

so the entire connection?

like the websocket conn just dies

its like the more work that gets done the quicker it disconnects, but connections that just idle maybe last 5hr+

if this is impossible it might be because im spawning async functions inside that call recurrent

If I am not mistaken your CPU time gets topped up on every incoming request.. So if you create a connection that only ever sends messages from the server, it is possible the DO might indeed be running out of CPU time

hey bestie did you figurue it out?

(I'm from the future - this is happening locally via miniflare :) )