Is there any way to get the number of opened connections in a pool?

fberrez · 2024-06-17T14:29:19.153Z

I thought it was connection.base.connections.length but it’s not.

alexbevi · 2024-06-17T15:51:35.650Z

Hey @fberrez,

Connection pool details aren’t exposed via any public APIs, however we do document an example of how you can do this in our connection pool monitoring examples:

function connectionPoolStatus(client) {
  let checkedOut = 0;
  function onCheckout() {
    checkedOut++;
  }
  function onCheckin() {
    checkedOut--;
  }
  function onClose() {
    client.removeListener('connectionCheckedOut', onCheckout);
    client.removeListener('connectionCheckedIn', onCheckin);
    checkedOut = NaN;
  }
  // Decreases count of connections checked out of the pool when connectionCheckedIn event is triggered
  client.on('connectionCheckedIn', onCheckin);
  // Increases count of connections checked out of the pool when connectionCheckedOut event is triggered
  client.on('connectionCheckedOut', onCheckout);
  // Cleans up event listeners when client is closed
  client.on('close', onClose);
  return {
    count: () => checkedOut,
    cleanUp: onClose
  };
}

fberrez · 2024-06-18T13:13:22.548Z

Hi @alexbevi ,

Thank you. for your “homemade” way to go.

I have now more data about my connection pools on my different apps. I have maybe one question about it.

I have this application that performs a lot of finds, inserts, updates and deletes on db1 and it performs finds only on db2 and db3.

image1254×830 39.7 KB

According to this graph, we can see that db1 has a median of 20 connections opened constantly (out of 20) while db2 and db3 has a median of 1 connection opened (out of 20).

With the informations I gave here, could it be considered as correct?

Thanks.

alexbevi · 2024-06-18T13:35:11.066Z

fberrez:

According to this graph, we can see that db1 has a median of 20 connections opened constantly (out of 20) while db2 and db3 has a median of 1 connection opened (out of 20).

With the informations I gave here, could it be considered as correct?

The connection pool is associated with the MongoClient instance; not a particular database, so it would be difficult to judge accuracy without more information

It would really depend on how you’re capturing/recording telemetry …

fberrez · 2024-06-18T13:51:30.487Z

Yes sorry I forgot to add that each MongoClient is connected to one specific database (the uri would be mongodb+srv://username:password@host.com/db1).

Also, I only log when a connection is checking out like:

// this.conn is a mongoose connection
// this.conn.getClient() returns the mongodbclient instance
// this.checkedout is initialised at 0 in my constructor
this.conn.getClient().on('connectionCheckedIn', () => {
  this.checkedout -= 1;
});

this.conn.getClient().on('connectionCheckedOut', (e) => {
  this.checkedout += 1;
  // logs only the used connections
  this.logger.info(`MongoDB[${this.name}] Connection is checked out.`, MONGO_INFOS.MONGODB_CHECKED_OUT, { checkedout: this.checkedout });
});

Geoduck · 2024-08-28T18:26:41.279Z

I have implemented the connectionCheckedOut`` and connectionCheckedIn` handlers exactly as in the example in the documentation, which alexbevi posted above, and I ran a load test.

I am consistently getting checkedOut becoming a negative value. I added some code to just count the number of each events, and the connectionCheckedIn is emitted more often than connectionCheckedOut!

By load, I mean I have 50 asynchronous functions all reading and writing to the same collection constantly (10ms gaps).

This is with node.js 6.6.2 driver, and mongoose 8.4.5

I compared to the internals on the pool, deep under the topology on the MongoClient, and the values on the pool make sense. The db I am running is NOT loadBalanced, so the driver code looks pretty straight forward in that case and I cannot see how that is possible. To ensure I wasn’t just adding the handlers too late, my test clears the pools and the checkedOut value properly resets to NaN, then seems to match the internals for a while, but eventually goes negative.

I added a connectionCheckOutStart handler. These match the connectionCheckedOut calls exactly, except for the occasional connectionCheckOutFailed (which is either due to clearing the pool or network error)

To me, this makes this technique pretty useless.