Hey,
I was wondering here if using {reactive: false} on my queries or changing from pub/sub to methods would be a better approach in places where I don’t need re activity. Does anyone benchmarked this or maybe it’s a simple and already answered question?
I use pub/sub several times on my code where I could change to something like this. How are you currently working with this things?
Tks
If you don’t actually need the reactivity, then it will certainly cause less overhead if you do turn it off. On the server that also helps in lowering memory usage and performance overhead.
I don’t have benchmarks for you, and I’m not sure how many people have already had to optimize performance at this level.
Most of the time the additional effort (i.e. resulting decreased ease of use) of moving from pub/sub to Meteor methods shouldn’t be worth thinking about this too much.
But I do understand the desire to always stay in keeping with what’s the most performant application of an API, if there are no other more important priorities to consider (such as ease of development; fewer lines of code to maintain etc).
If you have a specific case (cases) that you’re looking to optimize you could share some details about those. Optimization is usually something that should be done in a very deliberate and targeted effort. Otherwise sticking with the most standard and “good enough” patterns is often the best thing to do.
Effectively most of the answer is already implicitly stated, i.e. for me it’s ease of development & maintenance that take precedence over performance concerns where there are no large, unacceptable performance overheads generated.
One thing that I do always think about, at least regularly and in conjunction with publishing new releases, is server performance overhead and memory usage resulting from the “merge box” algorithm that’s tracking which clients are interested in which collections/data and what’s already on which client. That one could definitely get out of hand very quickly, if pub/sub is not used wisely and more than a handful of users hit the app at the same time.
So intending to not overpublish/oversubscribe is a really good idea and something to always consider once the app moves towards production use and the amounts of data and numbers of (concurrent) users get larger.
On the client, {reactive: false} provides a double benefit:
However, although it might be useful at debug time, it is usually not the way to go, as it causes cascading UX problems (many of them revealed later, in real situation with multiple users).
For me, most of the time, the right fix has been to move the query to a different place (after subscription is ready, when users actually clicks a menu, etc.) rather than to make it non-reactive.
There are really good points here. Just to tell a little about my case, Im
writing a New version of a marketplace that has about 480k u nique visitors
a month. One of the things that are reactive is the category list.
The category menu is displayed in every page, and so the top blog posts,
upcoming events and other simple things.
Do you have any thought on this case?
From what I understand of your case (a few small lists), I don’t think you need optimization. You can keep everything reactive.
Just inject your categories list with FastRender and don’t subscribe to them with Meteor.subscribe. That’ll give you static data on every route needed.