前言
最近在研究压力测试，发现是否打印日志对服务器的 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 的性能有很大影响。
在实际情况中，打印日志的目的往往是为了记录错误，如果什么日志都没有的话，也就难以找到问题的所在了，所以该打印日志的地方还是得打印。
但这次实验也告诉我们，没必要打印的日志就别打印了，没什么大用还影响服务器性能，所以在输出日志的地方还是得稍微思考下，是否真的有必要打印日志，即便真的要打印日志，也最好处理成根据配置输出不同级别的日志的情况。
本文作者：草梅友仁
本文地址：https://blog.cmyr.ltd/archives/2b5bf0d8.html
版权声明：转载请注明出处！