Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

We must have the ability to store json board files in a shared location (external storage or DB) so we could have scaled out WBO nodes #88

Open
VenkatesuNallu opened this issue Jun 9, 2020 · 5 comments

Comments

@VenkatesuNallu
Copy link

We are planning to roll out the product for wider usage in our org. There might be n number of users using the board and at times having a single wbo service node may not be scalable. We would like to have multiple WBO service running and then having a front ending server load balancing it. In such cases having the json files stored locally on the node would not work out and we need to have a shared storage or DB etc., to provide consistent results to the users. Also we need to take care of sync'ing the changes to json back to external storage or DB too.

@VenkatesuNallu
Copy link
Author

Also need to take care of if the websocket running on different node (in case of scaled out scenario) has the ability to concurrently update the same json file.

@lovasoa
Copy link
Owner

lovasoa commented Jun 9, 2020

Hello,
If you want to run a distributed WBO, the easiest is to let the load balancer distribute websocket connections to backends based on the board name. This will let you easily scale with the number of simultaneously active boards. If you want all the boards saved at the same place, you can simply mount a shared network drive and point WBO to it.

Since you are talking about concurrently updating the same json file, it looks like you also want to be able to distribute connections to the same board. This is a much more difficult problem, since all updates to a board have to reach all servers that have users connected to the board. There is a significant overhead involved. Even softwares like google docs do not implement that, and just limit the maximum number of users connected to a given document.

And out of curiosity: how many simultaneous users connected to the same board are you expecting ? Did you benchmark the use of a single server ? The official instance (https://wbo.ophir.dev/) is hosted on a single server, and scales quite well even during peak usage times.

@VenkatesuNallu
Copy link
Author

Hi,

Thanks for your response. Yes, to start with we might be 100-200 users using the whiteboard instance and playing around creating boards and collaborating with each other. They may be using the same board or their own private boards etc., The highest spike would be all 200 users connecting up to the same board. We do have our own customization UI service running on top of WBO which does authorization, user management stuffs, tools customization etc., and also have a API service to do few other functionalities.

Now assuming that our user base would go up to 1000-2000 users in a span of one month, a single web server that hosts my UI service nor the host that hosts WBO service would not be able to scale to it. So we planned to have multiple instances of WBO running and my UI service would redirects its requests to one of the WBO in a round robin manner. The challenge here is that I would expect both the instances of WBO to store the json files at same location so I have consistent board when any instance serve the request and user sees the latest and greatest change.

My questions are that -
-when there are multiple instance of WBO running, each would have its own websocket and hence when 2 users are connected to the same board served by two different instance of WBO (pointing to same json file though), would the changes be available to each other from in memory?

  • assuming that above works fine, when two users connected to same board updates the contents in the board, i assume both will try to update same json file, will there be any issues?

@lovasoa
Copy link
Owner

lovasoa commented Jun 9, 2020

We do have our own customization UI service running on top of WBO which does authorization, user management stuffs, tools customization etc.,

Oh that's nice ! Is it published somewhere ? WBO is published under the AGPL, so if you integrate it as a part of a larger system, that system has to be made available under the same license.

-when there are multiple instance of WBO running, each would have its own websocket and hence when 2 users are connected to the same board served by two different instance of WBO (pointing to same json file though), would the changes be available to each other from in memory?

No. You would have to implement a broadcast system; this is possible, but not trivial. That's what I was writing about above.

I strongly advise you to make concrete measures of how the server scales before making any architectural choices, though. And if you make them, it would be great if you could report them here.

@VenkatesuNallu
Copy link
Author

We do have our own customization UI service running on top of WBO which does authorization, user management stuffs, tools customization etc.,

Oh that's nice ! Is it published somewhere ? WBO is published under the AGPL, so if you integrate it as a part of a larger system, that system has to be made available under the same license.

Nope, we have not reached a stage where it can be published. Its just in requirements gathering step and formulating a plan to get the product out. I will get back to this as needed.

-when there are multiple instance of WBO running, each would have its own websocket and hence when 2 users are connected to the same board served by two different instance of WBO (pointing to same json file though), would the changes be available to each other from in memory?

No. You would have to implement a broadcast system; this is possible, but not trivial. That's what I was writing about above.

I strongly advise you to make concrete measures of how the server scales before making any architectural choices, though. And if you make them, it would be great if you could report them here.

Sure thank you!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants