-
Notifications
You must be signed in to change notification settings - Fork 10.3k
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
Virtualize the private chat experience for multiple small groups of users on one Rocket.Chat instance #630
Comments
Interesting, something like add teams to rocket chat, right? With this lib 1 user (email) can be part of only one group, so if I want to connect to more then one chat in the same instance I need to use 2 emails, right? |
idn, it would be ideal to somehow extend it to partition the user collection as well - more research than practical .. unless MDG would put it on their roadmap 😃 |
hey ... can we 'virtualise' the real email + an appearance id ... and then gen a unique guid email to be used by meteor?? just a thought the appearance id might just be a 'context identifier', from which white-labeled instance the user is logging in, for example: ([email protected] + 'rocketchat team') -> [email protected] |
@jaypanares - would you mind sharing your operating experience with this lib. Are you running 24 7 , any problems? |
I think implementing teams would potentially be the first step to this. If done right we could have the ability to isolate channels strictly to teams. Also allow just logging in to the team. A lot of customizations could be made using that approach. Even if completely different instances I probably wouldn't have multiple mongo instances. Just multiple db's for each, and cluster the db's for redundancy. Need to measure.. but I wouldn't think rocket.chat would be too heavy to run multiple instances. |
How about: I guess slack use the similar approach |
And: |
Some of this is being discussed over on #658 |
Shoudl we close this and keep all the discussion on #630? |
…c7fbf4 [Upstream Catchup] Merge RC:master to develop_pwa
We know one instance of Rocket.Chat can handle tens of thousands of users with ease already.
However, to provide Rocket.Chat service to a small group (5 users, say), it is still necessary to incur the cost of running a meteor and a mongo instance.
It would be ideal to be able to operate 2,000 private chats of 5 users each, on the same server/VPS config as the one that can handle a single 10,000 users public chat.
One solution is rely on post-docker hosting technologies like sandstorm.io that can freeze-dry and switch containers at a very high rate.
Another is to consider partitioning at the collection level. See the research link below, and an attempt by a community member to do something similar:
https://github.com/mizzao/meteor-partitioner
jaypanares@2b04cc4
Perhaps there are more alternatives.
Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.
The text was updated successfully, but these errors were encountered: