nodejs - ¿Por qué se recomienda no cerrar una conexión MongoDB en ningún lugar del código Node.js?
nodejs mongoose (3)
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 bloqueo 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.
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?
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);
});
});
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:
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.