Nodejs mongoose的问题，每次增删改查都要打开关闭连接吗？

Nodejs mongoose的问题，每次增删改查都要打开关闭连接吗？

问题

同问，Mongoose的问题，每次增删改查都要打开关闭连接吗？

问题是，我不关，他就挂在那了。

我的解决方案

使用 Mongoose 内置的连接池，配置如下：

const options = {  
  server: {
    auto_reconnect: true,
    poolSize: 10
  }
};

说明：

• poolSize 是连接池大小。
• auto_reconnect 是否自动重连接。

代码

// mongoose config
const mongoose = require('mongoose');  
const connectionString = 'mongodb://localhost:27017/exam_weixin';
const options = {};

options.server = {
  auto_reconnect: true,
  poolSize: 10
};

mongoose.connect(connectionString, options, function(err, res) {  
  if (err) {
    console.log('[mongoose log] Error connecting to: ' + connectionString + '. ' + err);
  } else {
    console.log('[mongoose log] Successfully connected to: ' + connectionString);
  }
});

const db = mongoose.connection;

db.on('error', console.error.bind(console, 'mongoose connection error:'));
db.once('open', function callback() {
  console.log('mongoose open success');
});

还有更好的方案？

通常情况下，不需要每次都手动打开和关闭 MongoDB 的连接。Mongoose 默认会管理连接池，并且在应用启动时连接到数据库，在应用退出时关闭连接。因此，你可以将连接逻辑放在一个单独的文件中，例如 db.js，并在应用启动时调用它。

例如，创建一个 db.js 文件：

const mongoose = require('mongoose');

const connectDB = async () => {
  try {
    await mongoose.connect('mongodb://localhost:27017/exam_weixin', {
      useNewUrlParser: true,
      useUnifiedTopology: true,
      server: {
        auto_reconnect: true,
        poolSize: 10
      }
    });
    console.log('MongoDB connected successfully');
  } catch (err) {
    console.error(`Error connecting to MongoDB: ${err.message}`);
    process.exit(1);
  }
};

module.exports = connectDB;

然后在你的主文件（如 app.js）中调用这个函数：

const express = require('express');
const connectDB = require('./db');

const app = express();

connectDB().then(() => {
  app.listen(3000, () => {
    console.log('Server is running on port 3000');
  });
}).catch((err) => {
  console.error(`Failed to start the server: ${err.message}`);
});

这样，你就可以确保在应用启动时建立连接，并在应用退出时关闭连接。

关于 pool size 的大小，这个回答不错。

The optimum size of a thread pool depends on the number of processors available and the nature of the tasks on the work queue. On an N-processor system for a work queue that will hold entirely compute-bound tasks, you will generally achieve maximum CPU utilization with a thread pool of N or N+1 threads. For tasks that may wait for I/O to complete – for example, a task that reads an HTTP request from a socket – you will want to increase the pool size beyond the number of available processors, because not all threads will be working at all times. Using profiling, you can estimate the ratio of waiting time (WT) to service time (ST) for a typical request. If we call this ratio WT/ST, for an N-processor system, you’ll want to have approximately N*(1+WT/ST) threads to keep the processors fully utilized. Processor utilization is not the only consideration in tuning the thread pool size. As the thread pool grows, you may encounter the limitations of the scheduler, available memory, or other system resources, such the number of sockets, open file handles, or database connections. So profile your application, if your threads are mostly cpu bound, then set the thread pools size to number of cores, or number of cores + 1. If you are spending most of your time waiting for database calls to complete, then experiment with a fairly large number of threads, and see how the application performs.