Node.js 코드의 아무 곳에서나 MongoDB 연결을 닫지 않는 것이 권장되는 이유

Node.js 코드의 아무 곳에서나 MongoDB 연결을 닫지 않는 것이 권장되는 이유는 무엇입니까?

---

다음은 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 에서는 "이것은 요청 풀링을 사용하지 않는 응용 프로그램의 정상적인 동작입니다"라고 언급되어 있습니다.

누군가가 이것을 이해하는 데 도움을 줄 수 있습니까?

---

MongoClient로 Db 연결을 한 번 열고 애플리케이션 전체에서 재사용합니다. 여러 db를 사용해야 하는 경우 Db 개체에서 .db 함수를 사용하여 동일한 기본 연결 풀을 사용하여 다른 db에서 작업합니다. 단일 차단 작업이 node.js 애플리케이션을 정지할 수 없도록 풀이 유지됩니다. 풀에 5개의 연결이 있는 경우 기본 크기입니다.

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

추가하는 것도 잊었습니다. 다른 답변에서 지적했듯이 새 TCP 연결을 설정하는 것은 시간과 메모리에 있어서 비용이 많이 들기 때문에 연결을 재사용하는 것입니다. 또한 새 연결로 인해 Db의 메모리도 사용하여 MongoDB에 새 스레드가 생성됩니다.

---

MongoDB는 데이터베이스 연결을 더 효율적으로 풀링하므로 mongodb.log에서 많은 연결이 열려 있는 것은 드문 일이 아닙니다.

However it is useful to close all connections when your app closes completely. This code is most excellent for doing this.

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

---

I am no node.js expert however I think the reason is relatively the same between most languages.

Making a connection is:

one of the most heavyweight things that the driver does. It can take hundreds of milliseconds to set up a connection correctly, even on a fast network.

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

Provided that is for PHP and the doc is a little out of date that part still applies even now and across most, if not all, drivers.

Each connection can also use a separate thread which causes obvious overhead.

It seems from:

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

That node.js still uses connection pooling to try and stop the overhead of making a connection. This, of course, no longer applies to other drivers like the PHP one.

It opens x amount of connections (default is 5) to your database server and transfers work to a free connection when data is needed and so reusing old connections averting this nasty process which can cause those logs: http://docs.mongodb.org/manual/faq/developers/#why-does-mongodb-log-so-many-connection-accepted-events and increase connection overhead.

ReferenceURL : https://stackoverflow.com/questions/14495975/why-is-it-recommended-not-to-close-a-mongodb-connection-anywhere-in-node-js-code