web-dev-qa-db-fra.com

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 non en la fermant? Est-ce que cela gère le regroupement des connexions en interne?

Mais dans MongoDB Docs , il est mentionné "C'est un comportement normal pour les applications qui n'utilisent pas le pool de requêtes"

Quelqu'un peut-il m'aider à comprendre cela?.

node.jsmongodb
53
Amol M Kulkarni

Vous ouvrez une fois une connexion à la base de données avec MongoClient et la réutilisez dans votre application. Si vous devez utiliser plusieurs bases de données, vous utilisez la fonction .db sur l'objet Db pour travailler sur une autre base de données en utilisant le même pool de connexions sous-jacent. Un pool est conservé pour garantir qu'une seule opération de blocage ne puisse 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'ajouter. Comme l’autre réponse a souligné la configuration d’une nouvelle connexion TCP est onéreuse en termes de temps et de mémoire, c’est pourquoi vous réutilisez des connexions. De plus, une nouvelle connexion entraînera la création d’un nouveau thread sur MongoDB en utilisant la mémoire sur le Db aussi.

54
christkv

Les connexions aux bases de données des pools MongoDB sont plus efficaces, il n’est donc pas rare que de nombreuses connexions soient ouvertes dans le fichier 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 cela.

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

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

Faire une connexion c'est:

une des choses les plus lourdes que le conducteur fait. Des centaines de millisecondes peuvent être nécessaires pour établir une connexion correctement, même sur un réseau rapide.

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

Pourvu que ce soit pour PHP et que la documentation est un peu dépassée, cette partie est toujours valable, même maintenant et sur la plupart, sinon tous les pilotes.

Chaque connexion peut également utiliser un thread distinct, ce 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 noeud.js utilise toujours le regroupement de connexions pour tenter d’arrêter la surcharge liée à l’établissement d’une connexion. Ceci, bien sûr, ne s'applique plus aux autres pilotes tels que PHP).

Il ouvre x nombre de connexions (la valeur par défaut est 5) sur votre serveur de base de données et les transferts fonctionnent sur une connexion libre lorsque des données sont nécessaires, ce qui permet de réutiliser d'anciennes connexions pour éviter ce processus désagréable susceptible de générer ces journaux: http://docs.mongodb.org/manual/faq/developers/# pourquoi-ce-que-mongodb-log-so-nombreux-événements-de-connexion-acceptés et augmenter le temps système de connexion.

9
Sammaye