前语
最近在研讨压力测验，发现是否打印日志对服务器的 QPS 有很大影响，下面来讨论一下这个问题。
根底预备
初始化项目
要测验功能，先得来个项目，本文中用到的被测项目是我自己写的 Nest.js 项目模板。
git clone https://github.com/CaoMeiYouRen/nest-template.git
cd nest-template
npm i
因为只是做个研讨，所以用什么结构来测都无所谓，找个自己喜爱的就行了。
为了简略起见，项目中都不带具体的业务逻辑。
去除 limit
因为默许的项目是装备了 limit 的，可能会限制 QPS，所以就先注释掉了
// main.ts 中
// app.use(limiter)
然后再编译运转项目
npm run build
npm start
这样就完结了被测项目的预备。
装置 autocannon
本次用来压力测验的东西是 autocannon，是一个 Node.js 写的压测东西，能够直接运用 npm 装置。
npm i -g autocannon
autocannon -v
运用 autocannon
autocannon 运用起来仍是非常简略的，首要的参数有以下几个：
-c/--connections NUM 并发衔接的数量，默许10
-p/--pipelining NUM 每个衔接的流水线恳求恳求数。默许1
-d/--duration SEC 履行的时间，单位秒
-m/--method METHOD 恳求类型 默许GET
-b/--body BODY 恳求报文体
运用例：
autocannon -c 10 -d 5 -p 1 http://127.0.0.1:3000
履行成果参阅：
深入研讨
在完结根底预备后，我就想研讨下日志对功能的影响。
默许状况（控制台和文件都输出日志）
作为基准，先看下默许装备了控制台和文件日志输出的 QPS：
// main.ts 中
app.use(fileLogger) // 文件日志
app.use(consoleLogger) // 控制台日志
履行命令：
autocannon -c 10 -d 5 -p 1 http://127.0.0.1:3000
履行成果：
能够看到，在开启控制台和文件日志输出的状况，均匀的 QPS 在 1100 左右。
下面就来测下其他状况。
仅控制台输出日志
// main.ts 中
// app.use(fileLogger) // 文件日志
app.use(consoleLogger) // 控制台日志
然后重新履行
npm run build && npm run start
这是为了采用出产环境代码进行压测，后续不再赘述。
履行代码：
autocannon -c 10 -d 5 -p 1 http://127.0.0.1:3000
履行成果：
能够看到均匀 QPS 进步到了 1600 左右！这证明了输出日志的确会对服务器功能造成必定影响。
仅文件输出日志
作为控制变量，还得看下仅文件输出日志会是什么状况。
// main.ts 中
app.use(fileLogger) // 文件日志
// app.use(consoleLogger) // 控制台日志
履行代码：
autocannon -c 10 -d 5 -p 1 http://127.0.0.1:3000
履行成果：
此刻的均匀 QPS 达到了 1700 左右，比仅控制台输出日志还要略高一点，看来在出产环境下仍是仅输出文件日志会好些。
无输出日志
已然去掉控制台日志和文件日志都能进步功能，那么把两个日志都去掉会怎么样呢？
// main.ts 中
// app.use(fileLogger) // 文件日志
// app.use(consoleLogger) // 控制台日志
履行代码：
autocannon -c 10 -d 5 -p 1 http://127.0.0.1:3000
履行成果：
此刻均匀 QPS 来到了惊人的 4500 左右！比默许状况翻了快 4 倍！看来不输出日志才是最快的！
总结
通过本次测验，得出的结论是：输出日志的确对 Nest.js 的功能有很大影响。
在实际状况中，打印日志的目的往往是为了记载过错，假如什么日志都没有的话，也就难以找到问题的地点了，所以该打印日志的地方仍是得打印。
但这次实验也告诉我们，没必要打印的日志就别打印了，没什么大用还影响服务器功能，所以在输出日志的地方仍是得稍微考虑下，是否真的有必要打印日志，即使真的要打印日志，也最好处理成依据装备输出不同级别的日志的状况。
本文作者：草梅友仁
本文地址：blog.cmyr.ltd/archives/2b…
版权声明：转载请注明出处！
