来研究下日志对 Nest.js 性能的影响

前言

最近在研究压力测试,发现是否打印日志对服务器的 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

执行结果参考:

image-20230408172552592

深入研究

在完成基础准备后,我就想研究下日志对性能的影响。

默认情况(控制台和文件都输出日志)

作为基准,先看下默认配置了控制台和文件日志输出的 QPS:

// main.ts 中       
app.use(fileLogger) // 文件日志
app.use(consoleLogger) // 控制台日志

执行命令:

autocannon -c 10 -d 5 -p 1 http://127.0.0.1:3000

执行结果:

image-20230408172949826

可以看到,在开启控制台和文件日志输出的情况,平均的 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

执行结果:

image-20230408173301759

可以看到平均 QPS 提高到了 1600 左右!这证明了输出日志确实会对服务器性能造成一定影响。

仅文件输出日志

作为控制变量,还得看下仅文件输出日志会是什么情况。

// main.ts 中       
app.use(fileLogger) // 文件日志
// app.use(consoleLogger) // 控制台日志

执行代码:

autocannon -c 10 -d 5 -p 1 http://127.0.0.1:3000

执行结果:

image-20230408173638633

此时的平均 QPS 达到了 1700 左右,比仅控制台输出日志还要略高一点,看来在生产环境下还是仅输出文件日志会好些。

无输出日志

既然去掉控制台日志和文件日志都能提高性能,那么把两个日志都去掉会怎么样呢?

// main.ts 中       
// app.use(fileLogger) // 文件日志
// app.use(consoleLogger) // 控制台日志

执行代码:

autocannon -c 10 -d 5 -p 1 http://127.0.0.1:3000

执行结果:

image-20230408173933686

此时平均 QPS 来到了惊人的 4500 左右!比默认情况翻了快 4 倍!看来不输出日志才是最快的!

总结

经过本次测试,得出的结论是:输出日志确实对 Nest.js 的性能有很大影响。

在实际情况中,打印日志的目的往往是为了记录错误,如果什么日志都没有的话,也就难以找到问题的所在了,所以该打印日志的地方还是得打印。

但这次实验也告诉我们,没必要打印的日志就别打印了,没什么大用还影响服务器性能,所以在输出日志的地方还是得稍微思考下,是否真的有必要打印日志,即便真的要打印日志,也最好处理成根据配置输出不同级别的日志的情况。