Subs manager & template-level subscriptions

[SachaG]

I've been looking at using Subs Manager with template-level subscriptions. If I understand correctly, what this package does is keep subscriptions open, and not just cache the data in Minimongo?

With template-level subscriptions, I might be opening 4-5 different subscriptions on each page. So if you navigate through 2-3 pages times, you can quickly end up with about 10 open subscriptions. I'm just wondering if that will be an issue from a performance point of view? Won't having that many extra subscriptions open add to the server load?

I don't know if it would make sense, but is there any way to cache the data in Minimongo without necessarily keeping all subscriptions open?

[SachaG]

Related: https://github.com/meteorhacks/subs-manager/issues/36

My issue is a bit different from template caching, as there are cases where I'm using the same data in different templates (and from different subscriptions…).

[SachaG]

OK, the way I handle this issue for now is by making caching optional at the template level:

var subscriber = enableCache ? Telescope.subsManager : instance;
var postsSubscription = subscriber.subscribe('postsList', subscriptionTerms);

This way I can hand-pick which templates cache their subscriptions, and which just use template.subscribe().

[arunoda]

It's depend. Keeping subscription does not add much overhead specially if there is oplog.

But stopping and creating new subscriptions take considerable amount of CPU.

I think you can control this easily with limiting the cache size and the time. On 2015 ජූලි 7, අඟහ at පෙ.ව. 9.22 Sacha Greif notifications@github.com wrote:

OK, the way I handle this issue for now is by making caching optional at the template level:

var subscriber = enableCache ? Telescope.subsManager : instance;var postsSubscription = subscriber.subscribe('postsList', subscriptionTerms);

This way I can hand-pick which templates cache their subscriptions, and which just use template.subscribe().

— Reply to this email directly or view it on GitHub https://github.com/meteorhacks/subs-manager/issues/48#issuecomment-119064790 .

[SachaG]

OK, that's good to know. I just deployed the new subscription caching to http://meta.telescopeapp.org/, seems to be working ok.

[arunoda]

Yep. It's working pretty good to me. May be you need to play with some values for cache control parameters.

On Tue, Jul 7, 2015 at 9:47 AM Sacha Greif notifications@github.com wrote:

OK, that's good to know. I just deployed the new subscription caching to http://meta.telescopeapp.org/, seems to be working ok.

— Reply to this email directly or view it on GitHub https://github.com/meteorhacks/subs-manager/issues/48#issuecomment-119068607 .

[funkyeah]

@SachaG so are you actually using subs-manager within the Template.templatename.onCreated helper? I'm assuming you aren't since you reference #36 above in which the question is whether that is even possible. How are you using subs-manager with template subscriptions?

[SachaG]

@funkyeah yes I am. As far as I can tell it works just fine. See http://www.telescopeapp.org/blog/telescope-weekly-2-subs-manager-fast-render/

[funkyeah]

Hey @SachaG I had an outstanding stackoverflow question on this topic. It didn't really go anywhere so I posted a bounty and eventually answered my own question with an example distilled from the Telescope code. http://stackoverflow.com/questions/29709863/how-would-you-use-subscription-managers-with-meteors-template-subscriptions

Would you mind taking a quick glance at it? If it's correct or close feel free to copy-paste-modify my answer and I'll award you the bounty.

[SachaG]

Yeah seems ok. Feel free to just give the bounty to yourself :)

[peterchoo]

Maybe a little late to the party, but I've been looking at using the subs-manager for my own project.

With some previous work I've played about with subscriptions and granularity, I'd noticed that if I subscribe to the same subscription twice, it pretty much returns instantly the second time (i.e. already subscribed, no need to change anything).

To get the {{Template.subscriptionsReady}} helper to work, I have essentially subscribed twice:

var Subs = new SubsManager();

Template.whatever.onCreated(function() {
  var self = this;

  self.autorun(function() {
    var whatever = Session.get('whatever');
    Subs.subscribe('whatever', whatever);
    self.subscribe('whatever', whatever);
  });
});

This has been especially useful as we have several routes which do different things with some of the same data.

So my question is this: how inefficient is this? Is this going to cause excess work on the server side, or is Meteor clever enough to say "oh, that's a subscription with the same argument - noop time!"?

[arunoda]

That's interesting. I'm quite not sure what's going on here. May be you still send the subscription to the server. But it don't get any data.

Could you check whether you are sending the subscription twice to the server. You can use Kadira Debug or something you can use to inspect DDP traffic.

[peterchoo]

@arunoda It is making two subscription requests, but as the subs manager is caching the result of the subscription, the server does not send need to send any new data, and so Template.subscriptionsReady() returns true as it normally would.

The downside is I end up with multiple subscriptions to the same data, and I don't know whether that will affect server performance or not.

[peterchoo]

Hmm, having looked through the code I'm not sure why it's making multiple subscriptions, as it should just re-activate the existing connection:

https://github.com/meteor/meteor/blob/master/packages/ddp/livedata_connection.js#L497-L518

[arunoda]

That's because subs-manager has it's own context and does not rely on the context it's runs on. Sending this twice is kind a bad since it has to do some stuff on the server.

[arunoda]

I think now we've a proper guide on using SubsManager with template level subs. So, I'm going to close this issue.