Perché è consigliabile non chiudere una connessione MongoDB da nessuna parte nel codice Node.js?

Considera il seguente è il codice 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 }); } 

Vedi il link per le migliori pratiche, che dice di non chiudere nessuna connessione

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

Ho visto il file di registro contiene i seguenti dati:

 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) 

Questo non crea un sovraccarico sul server aprendo più connessioni e non chiudendole. Gestisce internamente il pool di connessioni?

Ma in MongoDB Docs è menzionato “Questo è un comportamento normale per le applicazioni che non usano il pool di richieste”

Qualcuno può aiutarmi a capirlo.

Apri una connessione Db una volta con MongoClient e riutilizzalo nella tua applicazione. Se è necessario utilizzare più db’s, utilizzare la funzione .db sull’object Db per lavorare su un diverso db utilizzando lo stesso pool sottostante di connessioni. Viene mantenuto un pool per garantire che una singola operazione di blocco non possa bloccare l’applicazione node.js. Dimensione predefinita se 5 connessioni in un pool.

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

Ho anche dimenticato di aggiungere. Come l’altra risposta ha sottolineato, l’impostazione di una nuova connessione TCP è ESPENSIVA in termini di tempo e di memoria per cui si riutilizza le connessioni. Inoltre una nuova connessione farà sì che un nuovo Thread venga creato su MongoDB usando anche la memoria sul Db.

Non sono un esperto di node.js, tuttavia penso che la ragione sia relativamente la stessa tra la maggior parte delle lingue.

Fare una connessione è:

una delle cose più pesanti che fa il driver. Possono essere necessari centinaia di millisecondi per configurare correttamente una connessione, anche su una rete veloce.

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

A condizione che sia per PHP e che il documento sia un po ‘obsoleto, la parte si applica ancora anche adesso e attraverso la maggior parte, se non tutti, i driver.

Ogni connessione può anche utilizzare un thread separato che causa un overhead ovvio.

Sembra da:

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

Quel nodo.js utilizza ancora il pool di connessioni per provare a interrompere il sovraccarico di creazione di una connessione. Questo, ovviamente, non si applica più ad altri driver come quello PHP.

Si apre x quantità di connessioni (il valore predefinito è 5 ) al server del database e trasferisce il lavoro a una connessione gratuita quando i dati sono necessari e riutilizzando le vecchie connessioni evitando questo brutto processo che può causare tali log: http://docs.mongodb.org / manual / faq / developers / # why-does-mongodb-log-so-many-connection-accepted-events e aumento del sovraccarico della connessione.

Le connessioni al database di MongoDB pool sono più efficienti, quindi non è raro avere molte connessioni aperte nel mongodb.log

Tuttavia è utile chiudere tutte le connessioni quando l’app si chiude completamente. Questo codice è il più eccellente per farlo.

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