Dlaczego nie zaleca się zamykać połączenia MongoDB w dowolnym miejscu kodu Node.js?

Question

Rozważmy następujące jest kod 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 
}); 
} 

Zobacz link do najlepszych praktyk, które mówi, aby nie zamykać żadnych połączeń

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

Widziałem plik dziennika zawiera następujące dane:

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) 

Nie tworzy to narzutu na serwerze, otwierając wiele połączeń i nie zamykając it, czy wewnętrznie obsługuje buforowanie połączeń?

Ale w MongoDB Docs jest to wspomniane „To jest normalne zachowanie dla aplikacji, które nie korzystają z żądania grupującym”

Czy ktoś mógłby mi pomóc w zrozumieniu tego.

Answer 1

Otwierasz połączenie Db raz z MongoClient i używasz go ponownie w swojej aplikacji. Jeśli chcesz użyć wielu baz danych, użyj funkcji .db w obiekcie Db, aby pracować z inną bazą danych przy użyciu tej samej podstawowej puli połączeń. Pula jest przechowywana w celu zapewnienia, że ​​pojedyncza operacja blokowania nie może zablokować aplikacji node.js. Domyślny rozmiar, jeśli 5 połączeń w puli.

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

zapomniałem też dodać. Inna odpowiedź wskazywała na to, że konfiguracja nowego połączenia TCP jest DROGOWA i czasochłonna, dlatego pamiętaj, aby ponownie korzystać z połączeń. Również nowe połączenie spowoduje utworzenie nowego wątku na MongoDB przy użyciu pamięci na Db.

Answer 2

Nie jestem ekspertem od node.js, ale uważam, że powód jest względnie taki sam w przypadku większości języków.

Nawiązywanie połączenia jest:

jeden z najbardziej ciężkich rzeczy, że kierowca robi. Może zająć setki milisekund, aby poprawnie skonfigurować połączenie, nawet w szybkiej sieci.

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

Pod warunkiem, że jest dla PHP i doc jest trochę nieaktualny, że część nadal obowiązuje nawet teraz i przez większość, jeśli nie wszystkie sterowniki.

Każde połączenie może również używać osobnego wątku, co powoduje oczywisty narzut.

Wydaje się z:

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

To node.js nadal korzysta z puli połączeń, aby spróbować zatrzymać napowietrznej wykonaniu połączenia. To oczywiście nie ma już zastosowania do innych sterowników, takich jak PHP.

Otwiera x ilość połączeń (domyślnie jest 5) do serwera bazy danych i transfery pracować na wolnym związku, gdy dane są potrzebne, a więc ponowne wykorzystanie starych połączeń odwracając ten przykry proces, który może powodować te kłody: http://docs.mongodb.org/manual/faq/developers/#why-does-mongodb-log-so-many-connection-accepted-events i zwiększają obciążenie połączenia .

Answer 3

MongoDB baseny połączenia z bazą danych, aby być bardziej wydajne, więc nie jest niczym niezwykłym, aby mieć wiele połączeń otwartych w mongodb.log

Jednak warto zamknąć wszystkie połączenia, gdy aplikacja zamyka się całkowicie. Kod ten jest najbardziej doskonały do ​​robienia tego.