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

UserStatus.connections memory usage #42

Open
rclai opened this issue Nov 24, 2014 · 5 comments
Open

UserStatus.connections memory usage #42

rclai opened this issue Nov 24, 2014 · 5 comments
Labels

Comments

@rclai
Copy link

rclai commented Nov 24, 2014

Will there be a lot of memory consumption if the UserStatus.connections collection has like.. millions of user connections in it?

@mizzao
Copy link
Collaborator

mizzao commented Nov 24, 2014

No, it's in the database, but there will be memory usage based on publications because of the merge box.

Although, having a million connections probably requires you to have multiple node processes, which currently isn't supported on this package: #21.

@rclai
Copy link
Author

rclai commented Nov 25, 2014

If that collection is in the database why does it have a collection null option?

That was a very informative but also somewhat discouraging article. I love Meteor but I hope MDG figures out how to solve the merge box issue.

@mizzao
Copy link
Collaborator

mizzao commented Nov 25, 2014

Oh @rclai, you're right. It's not in the database. I was thinking of Meteor.users for some reason.

Anyway, other things will cause your app to crash way before you reach a million users, not this :)

@rclai
Copy link
Author

rclai commented Nov 27, 2014

Okay cool. I was wondering what your feedback is about this article and whether it has any relevance to this merge box issue?

https://kadira.io/academy/optimize-memory-usage/

@mizzao
Copy link
Collaborator

mizzao commented Nov 29, 2014

That talks about sharing observers (in the facts package this is known as observe multiplexers), which can cut down memory usage for identical queries between clients. But that's just for managing queries; each merge box is a cache of clients' data which still has to be maintained.

It also mentions using a method instead of a publication, which will help with this issue by saving memory for large publications that are updated infrequently. But it will be more work to implement, so avoid premature optimization :)

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

No branches or pull requests

2 participants