CPU cost of publications and subscriptions

help
1

I know we need to be carefull with publishing too much data. I’ve heard the stories about merge box issues related to CPU usage of the server.

I’m curious though. When will this “cost” start? Is it the definition of the publication (Meteor.publish) that will initiate the cost, or can you publish everything you want and the actual subscription initiates the cost? (E.g. will the server CPU shoot up by calling .publish on the server, or only after calling .subscribe on any connected client).

Cheers.

2

Short answer.
It has to do with how many subscribers you have for a publication. so the last exemple.

1 Like
3

Actual answer is: it’s depend on your app. But based on our data at Kadira, CPU usage for subscriptions is based on few simple things:

  • Number of documents it initially sends
  • Number of documents it changes after that
  • Number of oplog changes coming this subscriptions

So, it’s totally fine for your subscriptions to keep as much as you want. It has no impact.
Basically, CPU usage increases when the number of subscriptions get increased.

You can do a CPU profile and find out where your app spends CPU.

Right now, we are working on a Live Query monitoring feature to Kadira. With that, we get get which publications are responsible for CPU issues. This is how it’s looks like.

2512×1552 176 KB

4

Scaling meteor without oplog tailing

See the video linked in the above thread for more detailed information on the root of the issue.

5

Thanks for all the help, it helps altough it does feel like a whole can of works has just been opened :stuck_out_tongue: As in, scaling is still something that doesn’t feel fixed without workarounds. The thing is, that we’re already being CPU limited with 5 users (although each will have a couple of sessions open, so let’s say 50 concurrent users). And that’s with an app that is not even writing a lot…

Back to the drawing board I guess :frowning:

6

Many times it can be simple absence of correct indexes in mongo too.
If you are running both on little droplet.

1 Like
7

No that’s not the case, Mongo is running on a seperate server. It’s pure the server-side-app of Meteor/Node.

8

The O(no) number that keeps coming up anecdotally is 100 concurrent users in write heavy conditions. If you’re having issues with a mere 5 concurrent users, it’s not likely related to the oplog tailing issue.

Just as @arunoda suggested, profiling your app is what you need to do.

9

Of course. And we will :smile: . Hence this initial post in the forum to start and try to figure out what is a possible cause (or solution direction). Take note though, I did mention “50” concurrent users (sessions), busy users ;).