Meteor performance bottleneck - EDIT: poor oplog performance


I’m trying to streamline my web app, as it’s not quite as snappy (on initial load) as I’d like.

As I see it, the bottleneck could be in one of several places: Galaxy’s server (I have a single 512MB container), my app (whether in the publications or elsewhere), or mLab. If everything looks good on Kadira, what’s my next step?


Ugh, looks like oplog is slowing me down, according to Kadira. Latencies of 1200ms, 2200ms, etc. Same issue as this person:

Have I implemented something incorrectly? I thought oplog was supposed to improve performance.

Here’s an example of part of my publication that’s not performing so well:

Is this an issue with mLab? I’m on their lowest priced plan ($15/mo, shared). MongoDB Compass shows me that this query would’ve used the index:


Do you have any cronjob (f.e. a clean cronjob) that deletes/updates a lot of docs?


Have you compared the performance elsewhere (like the local, development instance)?

I’m also curious if you’ve looked at setting up publications asynchronously? If you have several publications, they are usually set up one after the other. However, that means that the set-up time is the end-to-end set-up time of all your publications. The alternative is to run them asynchronously, which gives you a set-up time as the longest single publication set-up time.

So, instead of:

Meteor.publish('one') { ... }
Meteor.publish('two') { ... }
Meteor.publish('three') { ... }
Meteor.publish('four') { ... }


Meteor.setTimeout(() => { Meteor.publish('one'); }, 0);
Meteor.setTimeout(() => { Meteor.publish('two'); }, 0);
Meteor.setTimeout(() => { Meteor.publish('three'); }, 0);
Meteor.setTimeout(() => { Meteor.publish('four'); }, 0);


@ffxsam we went through the same problems, especially with mlab, there’s no point in battling with mongodb oplog anymore, go to the next level:

Good luck!


Ok, it was my fault to some extent. I was being lazy with my publications and not limiting the fields sent to the client. :blush: And it’s not like each document had like 50 fields and I was sending them all. Some had maybe 8-9 fields, and I figured “what’s the harm?” I’ve cut that down to sending maybe 1-3 fields, and it’s made a significant difference.

I’ve got some other weird server-side delays going on that I need to figure out too (methods waiting for subscriptions when they don’t need to).

@diaconutheodor - thanks for that, I’ll check it out!