Why is it recommended not to close the MongoDB connection anywhere in Node.js code?

Question

Consider the following Node.js code:

function My_function1(_params) { db.once('open', function (err){ //Do some task 1 }); } function My_function2(_params) { db.once('open', function (err){ //Do some task 2 }); } 

See the best practice link for not closing any connections.

https://groups.google.com/forum/#!topic/node-mongodb-native/5cPt84TUsVg

I saw that the log file contains the following data:

 Fri Jan 18 11:00:03 Trying to start Windows service 'MongoDB' Fri Jan 18 11:00:03 Service running Fri Jan 18 11:00:03 [initandlisten] MongoDB starting : pid=1592 port=27017 dbpath=\data\db\ 64-bit host=AMOL-KULKARNI Fri Jan 18 11:00:03 [initandlisten] db version v2.2.1, pdfile version 4.5 Fri Jan 18 11:00:03 [initandlisten] git version: d6...e0685521b8bc7b98fd1fab8cfeb5ae Fri Jan 18 11:00:03 [initandlisten] build info: windows sys.getwindowsversion(major=6, minor=1, build=7601, platform=2, service_pack='Service Pack 1') BOOST_LIB_VERSION=1_49 Fri Jan 18 11:00:03 [initandlisten] options: { config: "c:\mongodb\mongod.cfg", logpath: "c:\mongodb\log\mongo.log", service: true } Fri Jan 18 11:00:03 [initandlisten] journal dir=/data/db/journal Fri Jan 18 11:00:03 [initandlisten] recover begin Fri Jan 18 11:00:04 [initandlisten] recover lsn: 6624179 Fri Jan 18 11:00:04 [initandlisten] recover /data/db/journal/j._0 Fri Jan 18 11:00:04 [initandlisten] recover skipping application of section seq:59343 < lsn:6624179 Fri Jan 18 11:00:04 [initandlisten] recover skipping application of section seq:118828 < lsn:6624179 Fri Jan 18 11:00:04 [initandlisten] recover skipping application of section seq:238138 < lsn:6624179 Fri Jan 18 11:00:04 [initandlisten] recover skipping application of section seq:835658 < lsn:6624179 Fri Jan 18 11:00:04 [initandlisten] recover skipping application of section seq:955218 < lsn:6624179 Fri Jan 18 11:00:04 [initandlisten] recover skipping application of section seq:3467218 < lsn:6624179 Fri Jan 18 11:00:04 [initandlisten] recover skipping application of section seq:3526418 < lsn:6624179 Fri Jan 18 11:00:04 [initandlisten] recover skipping application of section seq:3646154 < lsn:6624179 Fri Jan 18 11:00:04 [initandlisten] recover skipping application of section seq:3705844 < lsn:6624179 Fri Jan 18 11:00:04 [initandlisten] recover skipping application of section more... Fri Jan 18 11:00:05 [initandlisten] recover cleaning up Fri Jan 18 11:00:05 [initandlisten] removeJournalFiles Fri Jan 18 11:00:05 [initandlisten] recover done Fri Jan 18 11:00:10 [initandlisten] query MYDB.system.namespaces query: { options.temp: { $in: [ true, 1 ] } } ntoreturn:0 ntoskip:0 nscanned:5 keyUpdates:0 nreturned:0 reslen:20 577ms Fri Jan 18 11:00:10 [initandlisten] waiting for connections on port 27017 Fri Jan 18 11:00:10 [websvr] admin web console waiting for connections on port 28017 Fri Jan 18 11:01:10 [PeriodicTask::Runner] task: WriteBackManager::cleaner took: 32ms Fri Jan 18 13:36:27 [initandlisten] connection accepted from 192.168.0.1:50076 #1 (1 connection now open) Fri Jan 18 13:36:27 [initandlisten] connection accepted from 192.168.0.1:50077 #2 (2 connections now open) Fri Jan 18 13:36:27 [initandlisten] connection accepted from 192.168.0.1:50078 #3 (3 connections now open) Fri Jan 18 13:36:27 [initandlisten] connection accepted from 192.168.0.1:50079 #4 (4 connections now open) Fri Jan 18 13:36:27 [initandlisten] connection accepted from 192.168.0.1:50080 #5 (5 connections now open) Fri Jan 18 13:36:27 [initandlisten] connection accepted from 192.168.0.1:50081 #6 (6 connections now open) Fri Jan 18 13:36:27 [initandlisten] connection accepted from 192.168.0.1:50082 #7 (7 connections now open) Fri Jan 18 13:36:27 [initandlisten] connection accepted from 192.168.0.1:50083 #8 (8 connections now open) Fri Jan 18 13:36:27 [initandlisten] connection accepted from 192.168.0.1:50084 #9 (9 connections now open) Fri Jan 18 13:36:27 [initandlisten] connection accepted from 192.168.0.1:50085 #10 (10 connections now open) ........................................... Fri Jan 18 13:36:48 [initandlisten] connection accepted from 192.168.0.1:50092 #97 (97 connections now open) 

Does this create overhead on the server by opening several connections and not closing it, does it process the internal connection pool?

But MongoDB Docs mentions "This is normal behavior for applications that do not use the query pool"

Can someone help me figure this out.

Answer 1

You open a Db connection once with MongoClient and reuse it in your application. If you need to use multiple db, you use the .db function for the Db object to work with another db using the same base connection pool. The pool is stored to ensure that a single locking operation cannot freeze your node.js application. The default size if 5 connections in the pool.

http://mongodb.github.com/node-mongodb-native/driver-articles/mongoclient.html

I also forgot to add. Since another answer indicated that setting up a new TCP connection is EXPensive temporary and reasonable memory, why are you reusing connections. Also, the new connection will lead to the creation of a new thread on MongoDB using memory on Db.

Answer 2

I am not an expert on node.js, but I think the reason is relatively the same for most languages.

Creating a connection:

one of the hardest things a driver does. It may take hundreds of milliseconds to properly configure the connection, even on a fast network.

( http://php.net/manual/en/mongo.connecting.pools.php )

Provided that for PHP and the document a little outdated, this part is still applied even now and in most, if not all, drivers.

Each connection can also use a separate thread, which causes obvious overhead.

It seems from:

http://mongodb.github.com/node-mongodb-native/driver-articles/mongoclient.html#the-url-connection-format

So that node.js still uses the connection pool to try and stop the connection creation overhead. This, of course, no longer applies to other drivers such as PHP.

It opens x number of connections ( 5 by default) on the database server and transfers the work to a free connection when data is needed, and reusing old connections preventing this unpleasant process that these logs can cause: http: //docs.mongodb .org / manual / faq / developers / # why-does-mongodb-log-so-many-connection-accepted-events and increase the connection overhead.

Answer 3

MongoDB database connections are more efficient, so it’s not unusual for several connections to be opened in mongodb.log

However, it is useful to close all connections when your application closes completely. This code is the most excellent for this.

 process.on('SIGINT', function() { mongoose.connection.close(function () { console.log('Mongoose disconnected on app termination'); process.exit(0); }); });