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

de-emphasize resource hungry apps #288

Open
benatkin opened this issue Apr 21, 2017 · 1 comment · May be fixed by #350
Open

de-emphasize resource hungry apps #288

benatkin opened this issue Apr 21, 2017 · 1 comment · May be fixed by #350

Comments

@benatkin
Copy link

Rocket.Chat can be resource hungry due to its choice of MongoDB, which should be run in a cluster. It's the first suggestion on the Sandstorm website.

Nothing against Rocket.Chat but it seems if something like Sandstorm is going to need to take off it's going to need lightweight apps that are good at scaling down.

@kentonv
Copy link
Member

kentonv commented Apr 21, 2017

Hi Ben,

Sandstorm's tools for Meteor apps automatically configure Mongo to run in a mode where it reasonably efficient for the Sandstorm use case. Under Sandstorm there is no reason to run Mongo as a cluster, since the idea is that you scale by creating more instances of Rocket.Chat (e.g. for separate chat rooms) rather than try to scale up one instance. Several of the top apps on Sandstorm (e.g. Wekan) are Meteor apps that use Mongo, but we haven't seen any problem with this.

Rocket.Chat on Sandstorm does have one performance problem currently in that it's very slow to start, but that's not because of Mongo but rather some sort of startup processing Rocket.Chat does, which ought to be optimized better. We might be able to solve this directly in Sandstorm eventually by using snappy-start.

@ocdtrekkie ocdtrekkie linked a pull request Jun 16, 2022 that will close this issue
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants