Perché si raccomanda di non chiudere una connessione MongoDB ovunque nel codice Node.js?

Question

Considerare seguito è riportato il codice di 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 
}); 
} 

si veda il link per le migliori pratiche, che dice di non chiudere tutte le connessioni

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

ho visto 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 chiudendo esso, gestisce il pool di connessioni internamente?

Ma in MongoDB Docs è menzionato "Questo è un comportamento normale per le applicazioni che non utilizzano richiesta pooling"

Qualcuno può aiutarmi a capire questo.

Answer 1

È possibile aprire una connessione Db una volta con MongoClient e riutilizzarla nell'applicazione. Se è necessario utilizzare più db's, utilizzare la funzione .db sull'oggetto 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.

Answer 2

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

Esecuzione di una connessione è:

una delle cose più pesanti che il driver fa. 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 è per PHP e il doc è un po 'fuori moda che parte ancora si applica anche ora e in tutta la maggior parte, se non tutti, i driver.

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

Sembra da:

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

Che Node.JS usa ancora il pool di connessioni per cercare di fermare il sovraccarico di effettuare una connessione. Questo, ovviamente, non si applica più ad altri driver come quello PHP.

si apre x quantità di connessioni (di default è 5) al server di database e trasferisce lavorare a una connessione libera quando è necessaria dei dati e così riutilizzando vecchie connessioni scongiurare questo processo brutto che possono causare tali registri: http://docs.mongodb.org/manual/faq/developers/#why-does-mongodb-log-so-many-connection-accepted-events e aumentare la testa di connessione .

Answer 3

MongoDB connessioni al database piscine ad essere più efficienti, in modo da non è insolito avere molte connessioni aperte nel mongodb.log

Tuttavia è utile per chiudere tutte le connessioni quando la vostra applicazione 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); 
    }); 
});