Pourquoi est-il recommandé de ne pas fermer une connexion MongoDB dans le code Node.js?

Considérez ce qui suit est le code 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 }); }

Voir le lien pour les meilleures pratiques, qui dit de ne fermer aucune connexion

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

J’ai vu le fichier journal contient les données suivantes:

 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)

Cela ne crée-t-il pas une surcharge sur le serveur en ouvrant plusieurs connexions et en ne les fermant pas? Gère-t-il le regroupement des connexions en interne?

Mais dans MongoDB Docs, il est mentionné “Ceci est un comportement normal pour les applications qui n’utilisent pas le regroupement de requêtes”

Est-ce que quelqu’un peut m’aider à comprendre cela?

Vous ouvrez une connexion Db une fois avec MongoClient et vous la réutilisez dans votre application. Si vous devez utiliser plusieurs bases de données, utilisez la fonction .db sur l’object Db pour travailler sur une autre firebase database en utilisant le même pool de connexions sous-jacent. Un pool est conservé pour garantir qu’une opération de blocage unique ne peut pas geler votre application node.js. Taille par défaut si 5 connexions dans un pool.

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

J’ai aussi oublié d’append. Comme l’autre réponse indiquée, la configuration d’une nouvelle connexion TCP est EXPENSIVE au niveau du temps et de la mémoire, c’est pourquoi vous réutilisez les connexions. De même, une nouvelle connexion créera un nouveau thread sur MongoDB en utilisant également la mémoire sur la firebase database.

Je ne suis pas expert node.js mais je pense que la raison est relativement la même entre la plupart des langues.

Faire une connexion est:

l’une des choses les plus lourdes que le conducteur fait. La configuration d’une connexion peut prendre des centaines de millisecondes, même sur un réseau rapide.

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

Pourvu que ce soit pour PHP et que le document soit un peu obsolète, cette partie s’applique toujours, même maintenant, à la plupart, sinon à tous les pilotes.

Chaque connexion peut également utiliser un thread distinct qui entraîne une surcharge évidente.

Il semble de:

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

Ce node.js utilise toujours le regroupement de connexions pour essayer d’arrêter la surcharge liée à l’établissement d’une connexion. Ceci, bien sûr, ne s’applique plus aux autres pilotes comme celui de PHP.

Il ouvre un nombre x de connexions (la valeur par défaut est 5 ) à votre serveur de firebase database et transfère le travail à une connexion libre lorsque des données sont nécessaires et réutilisant ainsi les anciennes connexions pour éviter ce processus désagréable qui peut provoquer ces journaux: http://docs.mongodb.org / manual / faq / developers / # pourquoi-ne-mongodb-log-so-many-connexion-événements-événements et augmente la surcharge de la connexion.

MongoDB regroupe les connexions de bases de données pour être plus efficace, il n’est donc pas rare d’avoir plusieurs connexions ouvertes dans mongodb.log

Cependant, il est utile de fermer toutes les connexions lorsque votre application se ferme complètement. Ce code est le plus excellent pour ce faire.

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