2

We have a problem with our meteor server. When we publish 300 or so items with Meteor.publish/Meteor.subscribe the server increases its memory and eventually becomes unresponsive. We thought of: 1) monitor the number of reactive subscribtions / memory taken by an active subscription 2) make something like ,,one time publish" - ignore changes in server side collection

Any thoughts on how any of the above can be accomplished ? Or any other tips to debug /improve meteor app performance ? Thanks

user1528384
  • 103
  • 5

2 Answers2

2

zorlak's answer is good.

Some other things:

You can do a one-time publish by writing your own custom publisher via the this.set API, based on the code in _publishCursor. You'd do something like:

Meteor.publish("oneTimeQuery", function () {
  MyCollection.find().forEach(function (doc) {
    sub.added("collectionName", doc._id, doc);
  });
  sub.ready();
});

This does a query, sends its results down, and then never updates it again.

That said, we hope that Meteor's performance will be such that this is unnecessary!

I'd also like to add an easy way to get stats (like number of observed cursors) from an app to Meteor (exposed as an authenticated subscription) but haven't had the time yet.

David Glasser
  • 1,438
  • 13
  • 21
  • `this.flush()` seems to no longer exist in Meteor 0.6.5. Can you update your question with the correct way to do a one-time, non-tracked query in the current version of Meteor? That is, if we know the data set is static and there is no need to watch it for live data. – Andrew Mao Sep 16 '13 at 05:28
  • I notice you've added the facts stats package you referred to. Is this still the correct way to do a one-time / static publish a year later? – Wes Johnson Jan 14 '14 at 21:27
0

As of Meteor 0.5.1, one thing you can do is to remove dependencies on the userId from the publish function. If a publish function does not depend on which user is subscribing, then Meteor will cache the db query so it doesn't get slower as more users subscribe.

See this Meteor blog post: http://meteor.com/blog/2012/11/20/meteor-051-database-scaling

zorlak
  • 1,414
  • 10
  • 15