I spent quite a lot of time trying different versions back then, and nothing really stood out. I went through the profiler, and it wasn’t one thing – it looked like multiple things just took longer. I’m planning on getting back to it in the following months, but that’s about it for now. I also thought it may be related to the Node.js version (or even V8), but my experiments were inconclusive (i.e., it wasn’t always worse with the newer version).
Thanks for that. I guess we’ll have to just try it out ourselves and see if it affects us or not 
Are there plans for anyone from Meteor to look into this? I’m wondering if you guys have a test app with some performance tests that compare pub-sub / method speeds across different versions ?
I looked into it (I’m not a 100% Meteor guy, though 
), and I did not reproduce this problem in a few other applications (both small and decently sized). It wasn’t a very in-depth investigation, but it seems to be related to some publication patterns or packages.
Curious, what odd behavior were you seeing with reactive-aggregate?
Hey, so we were actually trying to figure this out this morning and we found it’s not actually the fault of that package. It’s more to do with a mix of how the aggregation unwind and tabular interplay. So if you do a lookup and then unwind but don’t specify preserveNullAndEmptyArrays and have some docs where there’s nothing to join - you’ll have less docs than expected by tabular so its behaviour is to wait to have all the docs before updating (which will never happen) rather than listening to when the publication is ready. So just adding preserveNullAndEmptyArrays: true inside our unwinds has fixed it.
3 Likes
I thought I’d mention here that we upgraded from 2.7.3 → 2.10.0 a week ago and haven’t seen any performance hit at all with extensive publishComposite use. After reading this I had expected a hit. Our DB is running the latest 5.x if that’s of interest.
1 Like
More than a year later, I’ve finally found the issue. And it’s so weird I just have to revive this old thread!
A brief reminder: we’re on 2.5.8 and every single version after that, caused our CI to use significantly more CPU and caused most of the tests to fail (or timeout). Locally, the app performed normally, even slightly faster.
I took yet another stab at it last week, and the problem is that… The app is now too fast. You see, because of the MongoDB driver upgrade and some deep Meteor changes (we’ve jumped to 2.16 in the end, but 2.6 is showing similar results), our methods got faster. And because of that, the webhooks sent after certain actions were not “already sent” when the client expected them. Overall, it’s just a couple % faster, but it was enough to say “it wasn’t sent yet”. So the client retried… Again and again. But then they were sent milliseconds after, so there was not a lot of them piling up – just a constant stream.
We’ll be rolling out this new version to production next week, but so far we see more or less the same CPU usage, slightly higher RAM usage (~4%), and visibly faster execution (E2E is faster by 5%).
That’s our success story allowing us to prepare the app for Meteor 3.
Finally.
Sounds like a race condition.
Yeah, at least kind of. It never happened on v2.5.8, it sometimes happened on 2.6, and always happened on 2.16.
What did you do to fix the CI?
By default we delay webhooks by 1 second. Now we changed it, so during E2E tests it’s 1 millisecond instead. It was enough to solve this issue.
2 Likes
Ok! Here:
Meteor Upgrade 1:
Meteor Upgrade 2:
From Updating Meteor from 2.7.3 to 2.8.2 made our database queries much slower - #34 by xet7 , also adding them here:
