A DO is always active if it has a socket
A DO is always active if it has a socket connected to it so in the specific case koudelka wanted it will always be more expensive.
JExactly, if you have an intermediate, all those other DOs no longer have an active web socket
USo you are just pinging the other DOs instead? Did you calculate the pricing of pinging it? It will also now be slower to give updates since you dont have a socket to the other DOs you want to get updates from.
JYeah, as mentioned, the large cost of durable objects + web sockets is the GB-s cost. You can play around on the calculator I linked to check it out.
Again, it would definitely be slower to take this approach, but would more than likely be a lot cheaper, unless you have a high RPS or a high average user->DO ratio (eg. 10 users per DO)
Again, it would definitely be slower to take this approach, but would more than likely be a lot cheaper, unless you have a high RPS or a high average user->DO ratio (eg. 10 users per DO)
UThe cost is probably not much more when you do a proxied websocket considering its like $1.60 / million seconds a DO is active for. And is it really worth losing the instant feedback moving to a pinging system? Probably not
JI would still disagree, if you had just 100 users who use a single DO each, active for a workday (8 hours * 30 days, 12 msg/min), you'd pay only ~$5 in calling DOs instead of WSs. But if you had 100 active DOs for that time, you'd pay ~$136 for the month (excluding free tier.)
I'll add calculation below
Total requests: 100 users x 12 msg/min x 60 minutes x 8 hrs x 30 days = ~17m reqs x $0.15/1m req = $2.58
Total request time: 17m reqs x 50ms/req / 1000 ms x $1.6/1m seconds = $1.36
... the rest tbd
I'll add calculation below
Total requests: 100 users x 12 msg/min x 60 minutes x 8 hrs x 30 days = ~17m reqs x $0.15/1m req = $2.58
Total request time: 17m reqs x 50ms/req / 1000 ms x $1.6/1m seconds = $1.36
... the rest tbd
UYou would still have to pay for at least 100 active DOs on either solution.
Just the WS -> WS proxy is 100 * n
And the WS -> Pinging is only 100
Unless you are trying to suggest connecting every single user to the same proxy DO which would have extreme performance impact because DO's are single threaded and good luck at any scale with that.
Just the WS -> WS proxy is 100 * n
And the WS -> Pinging is only 100
Unless you are trying to suggest connecting every single user to the same proxy DO which would have extreme performance impact because DO's are single threaded and good luck at any scale with that.
JYou don't have 100 active DOs though, you only have 1 DO that would be active 24/7, the rest are only active when invoked, and would only be active for say 20ms/msg.
UOk so you are suggesting trying to use a singular DO as the proxy for the websockets. That wont work at any scale.
UDOs are single threaded that would cause lots of issues.
JThe only thing the proxy is doing is proxying, it doesn't need to block on concurrent requests.
JThe single thread would be active when figuring out where to route, but the rest of the duration is async and would handle other requests
UIf you want to go with that approach feel free but you will have performance issues doing that I can promise you that.
UIt might work fine if you have small scale but if you get any number of users it will not perform and you will get tons of disconnects
JYep, as mentioned in my original message, it would definitely be slower since the DOs are not necessarily in the same location haha.
Not sure I agree on disconnects, but I'd have to build a POC to demo
Not sure I agree on disconnects, but I'd have to build a POC to demo
UA POC wont have issues because it has very small traffic. A real world production app all going to a single DO which is single threaded and only has 128MB of ram = crashing galore.
JThe POC would be load testing, I agree it doesn't do anything to have simple single user thing
UYeah if you load test you will see the issues I am talking about immediately. DOs can process about 500 HTTP requests per second before slowing down and eventually dying. WebSocket connections also take up ram so you will be limited on the total number of users connected to any given DO and the number of messages that can be received and sent out.
JYou might be right, I look forward to seeing it fail or succeed 