Por que é recomendado não fechar uma conexão do MongoDB em algum lugar no código Node.js?

Considere a seguir o código do 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 }); } 

Veja o link para a prática recomendada, que diz para não fechar nenhuma conexão

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

Eu vi o arquivo de log contém os seguintes dados:

 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) 

Isso não cria uma sobrecarga no servidor, abrindo várias conexões e não fechando-as. Ele trata o pool de conexões internamente?

Mas no MongoDB Docs é mencionado “Esse é um comportamento normal para aplicativos que não usam pool de solicitações”

Alguém pode me ajudar a entender isso.

Você abre uma conexão Db uma vez com o MongoClient e a reutiliza em seu aplicativo. Se você precisar usar vários bancos de dados, use a function .db no object Db para trabalhar em um database diferente usando o mesmo conjunto de conexões subjacente. Um pool é mantido para assegurar que uma única operação de bloqueio não possa congelar seu aplicativo node.js. Tamanho padrão se 5 conexões em um pool.

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

Eu também esqueci de adicionar. Como a outra resposta apontou, a configuração de uma nova conexão TCP é EXPENSIVA no tempo e na memory, e é por isso que você reutiliza as conexões. Além disso, uma nova conexão fará com que um novo Thread seja criado no MongoDB usando memory no Db também.

Eu não sou especialista em node.js, mas acho que a razão é relativamente a mesma entre a maioria dos idiomas.

Fazer uma conexão é:

uma das coisas mais pesadas que o motorista faz. Pode levar centenas de milissegundos para configurar uma conexão corretamente, mesmo em uma rede rápida.

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

Contanto que seja para o PHP e o documento esteja um pouco desatualizado, essa parte ainda se aplica mesmo agora e na maioria dos drivers, se não todos.

Cada conexão também pode usar um thread separado, o que causa uma sobrecarga óbvia.

Parece de:

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

Esse node.js ainda usa o pool de conexões para tentar parar a sobrecarga de fazer uma conexão. Isso, claro, não se aplica mais a outros drivers como o PHP.

Ele abre uma quantidade x de conexões (o padrão é 5 ) para seu servidor de database e transfere o trabalho para uma conexão livre quando os dados são necessários e reutilizando conexões antigas evitando esse processo desagradável que pode causar esses logs: http://docs.mongodb.org / manual / faq / developers / # why-does-mongodb-log-so-many-connection-accepted-events e aumenta a sobrecarga da conexão.

O MongoDB agrupa as conexões com o database para serem mais eficientes, portanto, não é incomum ter muitas conexões abertas no mongodb.log

No entanto, é útil fechar todas as conexões quando seu aplicativo é fechado completamente. Este código é o mais excelente para fazer isso.

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