How Meteor manage Mongo connections?

performance
1

Hello everyone,
we have an app and see that number of Mongo connections grow as users login and use our app. We do not see those connections being released after users close browser windows and we suspect that’s causing performance issues… Few questions, if you don’t mind:

  1. How db connections are managed in Meteor? Are they managed by Meteor, Node or Mongo itself decide how many connections to open and maintain?
  2. What’s causing the growth of open Mongo connections? Is that ‘one-per-subscription’ or ‘one-per-user’ kind of thing?
  3. Are we supposed to explicitly track user activity and close connections/subscriptions in our app?

Thank you!

2

Hi,

Mongo connections in Meteor are managed per cursor. Each cursor represents a unique query. All documents matched by this query will be stored into a cache which is Minimongo. When 2 clients subscribe with exactly the same query, then there will only be one cursor connected. It basically means that in order to reduce the amount of connections, you will have to reuse queries.

You can reuse queries by letting people subscribe to a cursor with exactly the same mongo selector.

1 Like
3

That’s good to know, thank you!
If I understand you correctly, that means Meteor is supposed to close/release a DB connection once all clients stop their subscription to connection’s cursor, correct? Are we supposed to manually stop all subscriptions when user close the browser or Meteor track that and does that for us somehow?

Thank you!

4

If you close your browser, all subscriptions will stop. Meteor does this with its live connection. When there is a disconnect, the subscription will be cancelled. Same thing for when templates or components are destroyed / unmounted eg:

const ReactComponent = () => (<div>Some stuff</div>);

export default withTracker(() => {
  Meteor.subscribe('articles'); // Will unsubscribe
})(ReactComponent);

Similarly

Template.something.onCreated(function() {
  this.subscribe('articles'); // Will unsubscribe on destroy
});
5

Thank you, @cloudspider!

6

Hi @cloudspider, I just stumbled across this old post and wanted to clarify it a bit more.

From my understanding, things work like this:

  1. Under normal circumstances, there is a single DDP connection between each client and a Meteor server. It’s true that each cursor will occupy additional memory on the Meteor server, but regardless how many cursors that client has subscribed to, they will all flow over the same DDP connection. So 10 clients with 5 cursors each will mean 10 DDP connections and 50 cursors managed on the Meteor server.

  2. Likewise a Meteor server uses a small pool of database connections (possibly 5 according to this old post - Many database connections · Issue #3097 · meteor/meteor · GitHub) to tail the oplog regardless of how many clients are connected to that Meteor server and regardless of how many cursors it is currently managing.

So when you say that “Mongo connections in Meteor are managed per cursor” and “in order to reduce the amount of connections, you will have to reuse queries” I don’t think those 2 statements are quite correct. AFAIK, the number of connections, either DDP connections or database connections, isn’t affected by the number of queries or cursors.

Of course, if you have multiple Meteor servers, then each server would need a separate connection to the DB but that’s a different issue.

Could anyone let me know if any of my assumptions above are wrong? I’ve done quite a bit of Meteor dev work in the past but have been mostly out of the Meteor loop since late 2018 and just getting back into things again now (upgrading an old app to Meteor 1.10 and migrating from Compose to Atlas M2 shared tier - $9/month for MongoDB yay!). So I’m hoping DDP and oplog tailing hasn’t changed since 2018!

Thanks :slight_smile:

7

hi. I need to be careful now, because I’ve been out of the loop for a year too. Just returned a few weeks ago.

In Meteor, the cursor represents a resultset as a reactive data source. 1 or more clients can subscribe to this same data-source. So It could be that there are just 5 active cursors shared among 10 different connections. That’s assuming that they’ve subscribed with exactly the same parameters.

I need to check. Its been too long. You might be right :slight_smile:

8

Yes right, the example in my head was that each query had a different selector but if everyone is subscribed to the same query selector then it would be just 10 cursors, not 50.

I know, it’s been over a year, sorry to make your head hurt :laughing:

9

Well. Coincidentally I started diving in again. This time with the intent to simplify and decouple things when I have enough knowledge. :sweat_smile:

10

Nice! Welcome back. I still haven’t found anything better than Meteor for the majority of use cases I’ve dealt with. Anytime I have to work on an app without it I get a painful reminder of how nice it is to work with.

1 Like
11

Funny. I stumbled upon cloudspider’s statement just because of that. Was getting worried if Meteor would crack the max number of connections if it really used one MongoDB connection per cursor.

1 Like