69

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
});
}

接続を閉じないというベスト プラクティスのリンクを参照してください。

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

ログ ファイルに次のデータが含まれていることを確認しました。

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)

複数の接続を開いて閉じないことで、サーバーにオーバーヘッドが発生しませんか?内部で接続プールを処理しますか?

しかし、MongoDB Docsには、「これは、リクエスト プーリングを使用しないアプリケーションの通常の動作です」と記載されています。

誰かがこれを理解するのを手伝ってくれますか?

4

3 に答える 3

73

MongoClient で Db 接続を 1 回開くと、それをアプリケーション全体で再利用できます。複数のデータベースを使用する必要がある場合は、Db オブジェクトで .db 関数を使用して、同じ基礎となる接続プールを使用して別のデータベースで作業します。単一のブロック操作で node.js アプリケーションがフリーズしないように、プールが保持されます。プール内の接続数が 5 の場合のデフォルト サイズ。

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

私も追加するのを忘れていました。他の回答が指摘したように、新しいTCP接続の設定は時間的にもメモリ的にも高価であるため、接続を再利用します。また、新しい接続により、Db のメモリも使用して MongoDB に新しいスレッドが作成されます。

于 2013-01-30T15:41:41.633 に答える
24

MongoDB はデータベース接続をより効率的にプールするため、mongodb.log で多くの接続が開いていることは珍しくありません。

ただし、アプリが完全に閉じたときにすべての接続を閉じると便利です。このコードは、これを行うのに最も優れています。

process.on('SIGINT', function() {
  mongoose.connection.close(function () {
    console.log('Mongoose disconnected on app termination');
    process.exit(0);
  });
});
于 2015-01-13T03:23:42.077 に答える
10

私は node.js の専門家ではありませんが、理由はほとんどの言語で比較的同じだと思います。

接続の作成は次のとおりです。

ドライバーが行う最も重いことの 1 つです。高速ネットワークでも、接続を正しく設定するには数百ミリ秒かかる場合があります。

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

それがPHP用であり、ドキュメントが少し古くなっている場合、その部分は現在でも、すべてではないにしてもほとんどのドライバーに適用されます。

各接続は、明らかなオーバーヘッドを引き起こす個別のスレッドを使用することもできます。

それは次のようです：

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

その node.js は引き続き接続プーリングを使用して、接続のオーバーヘッドを試みて停止します。もちろん、これは PHP などの他のドライバーには当てはまりません。

xデータベース サーバーへの接続数 (デフォルトは) を開き5、データが必要なときに空き接続に作業を転送し、古い接続を再利用して、これらのログを引き起こす可能性のあるこの厄介なプロセスを回避します。

https://docs.mongodb.com/manual/faq/diagnostics/#why-does-mongodb-log-so-many-connection-accepted-events

于 2013-01-24T09:09:57.663 に答える