You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Virtualize the private chat experience for multiple small groups of users on one Rocket.Chat instance #630
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:
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 😃
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:
1 a reg and longin instance
2 one email can create and join mutlple team, can switch to other teams after login
3 redirect teams(url, such as xx.rocket.com ) to different rocket chat instance(on the same host or not), instance connetted to one or more(if neccessary) db according the db config of these teams
4 dynamically migrate one team from one instance to another by the team members
And:
1 one instance have reg,login,team creation and all rocket features
2 when app need to expand to more than one instance, just start one, and shift more chat traffic to he new one
Activity
rodrigok commentedon Aug 30, 2015
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?
Sing-Li commentedon Aug 30, 2015
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 😃
Sing-Li commentedon Aug 30, 2015
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:
(singli@hisemail.com + 'rocketchat team') -> kskfjsafosajdfasf@dsalfsakfaslf.com
(singli@hisemail.com + 'sings own family chat') -> o24i3i435o35345@oi324323432.com
Sing-Li commentedon Aug 30, 2015
@jaypanares - would you mind sharing your operating experience with this lib. Are you running 24 7 , any problems?
geekgonecrazy commentedon Aug 31, 2015
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.
liuliming2008 commentedon Sep 12, 2015
How about:
1 a reg and longin instance
2 one email can create and join mutlple team, can switch to other teams after login
3 redirect teams(url, such as xx.rocket.com ) to different rocket chat instance(on the same host or not), instance connetted to one or more(if neccessary) db according the db config of these teams
4 dynamically migrate one team from one instance to another by the team members
I guess slack use the similar approach
liuliming2008 commentedon Sep 14, 2015
And:
1 one instance have reg,login,team creation and all rocket features
2 when app need to expand to more than one instance, just start one, and shift more chat traffic to he new one
geekgonecrazy commentedon Sep 14, 2015
Some of this is being discussed over on #658
engelgabriel commentedon Feb 11, 2016
Shoudl we close this and keep all the discussion on #630?
Merge pull request RocketChat#630 from WideChat/develop_pwa-catchup-0…