Migrate from Socket.IO
Socket.io is not performant at scale, we will be limited to ~10k msg/s per socket instance which might seem like a lot but really it isn't. Socket.io is not really relevant in 2020, ws is a viable option and as the order of events might not be so relevant to WBO you might get away w/ something even more progressive such as an UDP-esque approach.
ws would seem like the quickest win.
We're going to move our Etherpad clients from Etherdraw to WBO so thanks for the project :)
We also might want to document load testing / scaling etc. In Etherpad we have loads of tools for this and I built some for Etherdraw that are available to be referred to :)
Hello, Moving from socket.io to a websocket-only solution would be a regression... Currently, WBO works in environments were websockets are blocked and on browsers where they are not available. Did you run actual load tests and found socket.io to be the limiting factor ? If you want to document the process of load testing, this will be very welcome !
Hi @lovasoa -
Websockets are pretty much universally supported now. source: https://caniuse.com/?search=websockets
Do you collect stats on how many connections fall back to long polling / xhr? We do/did and it was a tiny amount and mostly due to some weird internal failure / bizarre double nat / misconfigured networks.
We ran actual load tests, of course :) So have others, see https://stackoverflow.com/questions/64506823/how-can-i-make-socketio-more-performant for details. If you want a copy of our load test stats I can pull them up but we're confident socket.io is our bottle neck and will be yours.
https://github.com/ether/etherpad-load-test is Etherpad load test docs and repo.
https://github.com/JohnMcLear/etherdraw-stresstest is the Etherdraw stress tests.
It should be really easy to port them over to WBO, if I get time I will but I don't feel it solves the problem as I am confident socket.io is not going to be as performant as you will need at scale :)
We're (Etherpad) in the process of migrating away from socket.io so perhaps as our progress unfolds I can share additional info at that point.
Yes, modern web browsers support web sockets (and socket.io uses that). But WBO currently not only supports IE9, but also all the various contexts in which websockets are not available: HTTP-only proxies, load balancers, firewalls are all reasons why websockets connections can fail. Websockets are available on wbo.ophir.dev, but I (fortunately) do not have statistics about who installs wbo where. Additionally, migrating away from socket.io would mean either losing features or having to reimplement most of socket.io in WBO itself: multiplexing, disconnection detection and smart automatic reconnection, and as we said, longpolling.
I think if there are performance issues in socket.io, they are better fixed in socket.io itself, rather than having all projects reimplement all of the library independently themselves.
And doing the work of switching from a library that handles X requests per second to a library that handles Y requests per second would only benefit people who need to handle between X and Y requests per second.
What I think is a good long-term solution to scaling WBO is to allow it to work in a distributed fashion: having multiple instances of WBO running on multiple machines should allow scaling to much larger deployments than a single server with a different websockets library.
What do you think?
@lovasoa I completely understand. I think the fear of migrating from Socket.io to WS is understandable. RE stats from wbo.ophir.dev I think it would be a useful experiment to see those stats. Obviously I don't expect you to share them but I think you might be surprised how many clients drop down from ws nowadays :) But I love to be proved wrong if you can!
RE socketio > ws, yep you lose some features, but nothing that can't be relatively easily re-implemented. Or, you could look at "uwebsocket" which tries to be more of a "drop in":)
I'd love to see the socket.io performance fixed, that would be amazing! I think their is no effort in the project to do that but perhaps I approached their community wrong ;( Perhaps you can approach the problem a different way.
If we(both WBO and Etherpad) can stick with Socket.io that is a dream outcome :)