¿Por qué se recomienda no cerrar una conexión MongoDB en ningún lugar del código Node.js?

Considera seguir el código Node.js:

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 }); } 

Vea el enlace de mejores prácticas, que dice no cerrar ninguna conexión

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

He visto el archivo de registro contiene los siguientes datos:

 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) 

¿Esto no crea una sobrecarga en el servidor al abrir varias conexiones y no cerrarlas? ¿Maneja la agrupación de conexiones internamente?

Pero en MongoDB Docs se menciona “Este es el comportamiento normal de las aplicaciones que no usan el agrupamiento de solicitudes”

¿Alguien puede ayudarme a entender esto?

Abre una conexión Db una vez con MongoClient y la vuelve a utilizar en su aplicación. Si necesita utilizar múltiples db, use la función .db en el objeto Db para trabajar en un db diferente utilizando el mismo grupo de conexiones subyacente. Se mantiene un grupo para garantizar que una sola operación de locking no pueda congelar su aplicación node.js. Tamaño predeterminado si 5 conexiones en un grupo.

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

También olvidé agregar. Como la otra respuesta señaló que la configuración de una nueva conexión TCP es EXPENSIVA en el tiempo y la memoria, por eso reutiliza las conexiones. Además, una nueva conexión provocará la creación de un nuevo subproceso en MongoDB utilizando también memoria en el Db.

No soy un experto en node.js, pero creo que la razón es relativamente la misma entre la mayoría de los idiomas.

Hacer una conexión es:

una de las cosas más pesadas que hace el conductor. Puede llevar cientos de milisegundos configurar una conexión correctamente, incluso en una red rápida.

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

Siempre que sea para PHP y el documento esté un poco desactualizado, esa parte aún se aplica incluso ahora y en la mayoría de los controladores, si no en todos.

Cada conexión también puede usar un hilo separado que causa una sobrecarga obvia.

Parece de:

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

Ese node.js aún usa la agrupación de conexiones para intentar detener la sobrecarga de hacer una conexión. Esto, por supuesto, ya no se aplica a otros controladores como el de PHP.

Abre x cantidad de conexiones (por defecto es 5 ) a su servidor de base de datos y transfiere el trabajo a una conexión gratuita cuando se necesitan datos y reutiliza conexiones antiguas que evitan este desagradable proceso que puede causar esos registros: http://docs.mongodb.org / manual / faq / developers / # por qué-does-mongodb-log-so-many-connection-accepted-events y aumenta la sobrecarga de conexión.

MongoDB agrupa las conexiones de la base de datos para que sean más eficientes, por lo que no es inusual tener muchas conexiones abiertas en mongodb.log

Sin embargo, es útil cerrar todas las conexiones cuando la aplicación se cierre por completo. Este código es excelente para hacer esto.

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