nestjs vs plain express 性能
nestjs vs plain express performance
我刚刚在一个简单的 nest 控制器上测试了性能,returns get 请求中的文本(无数据库)。
以及与 express 相同的简单 GET 控制器(中间件)。
我使用了 WRK 工具来测试性能。
因此,plain express 比 nestjs 快 2 倍。
为什么 nestjs 会产生如此多的开销?
更新 - 2020 年 3 月 17 日
我们现在 运行 为每个新 PR 设置基准。最新的基准之一可以在这里找到:https://github.com/nestjs/nest/runs/482105333
Req/sec Trans/sec
Nest-Express 15370 3.17MB
Nest-Fastify 30001 4.38MB
Express 17208 3.53MB
Fastify 33578 4.87MB
这意味着 Nest + FastifyAdapter
现在比 express 快 2 倍。
更新 - 2018 年 9 月 22 日
基准目录已添加到存储库:https://github.com/nestjs/nest/blob/master/benchmarks/all_output.txt(您也可以 运行 在您的计算机上进行基准测试)。
更新 - 24.06.2018
Nest v5.0.0
支持 fastify。 Fastify + Nest 集成甚至比普通(!)express 更高效。
下表显示了 Nest 与普通快速路由处理程序相比所做的事情:
- 它用 try..catch 块包围你的路由处理程序主体
- 它使每个路由处理程序
async
- 它创建一个全球快速路由器
- 它为每个控制器创建一个单独的路由器
- 它绑定错误处理中间件
- 它绑定
body-parser
中间件(json
和扩展 urlencoded
)
所有提到的事情都反映了一个真实世界的例子(可能 99.9% 的快递应用程序也必须这样做,这是不可避免的)。这意味着如果你想比较 Express 和 Nest 的性能,你应该 至少 涵盖以上几点。与以下示例的比较:
app.get('/', (req, res, next) => res.status(200).send('Hello world'));
在这种情况下是不公平的,因为这还不够。当我涵盖这些要点时,这就是我收到的(表达 4.16.2):
Running 10s test @ http://localhost:3000
1024 connections
Stat Avg Stdev Max
Latency (ms) 225.67 109.97 762
Req/Sec 4560 1034.78 5335
Bytes/Sec 990 kB 226 kB 1.18 MB
46k requests in 10s, 9.8 MB read
另外,Nest 必须:
- 识别结果是否为 Promise/Observable/plain 值
- 根据结果类型,使用
send()
或json()
(+1条件)
- 添加 3 个条件(
if
语句)来检查管道、拦截器和守卫
Nest (4.5.8) 有一个输出:
Running 10s test @ http://localhost:3000
1024 connections
Stat Avg Stdev Max
Latency (ms) 297.79 55.5 593
Req/Sec 3433.2 367.84 3649
Bytes/Sec 740 kB 81.9 kB 819 kB
34k requests in 10s, 7.41 MB read
这意味着 Nest 性能约为 79%(-21%)。这是由于上述原因,而且,因为 Nest 与 Node 6.11.x 兼容,这意味着它不能在幕后使用 async/await - 它必须使用生成器。
根据这些数据得出什么结论? None,因为我们不习惯创建只有 returns 没有任何异步内容的纯字符串的应用程序。与 Hello world
的比较没有任何意义,它只是一个花絮:)
PS。我使用了 autocannon
库 https://github.com/mcollina/autocannon
autocannon -c 1024 -t30 http://localhost:3000
我刚刚在一个简单的 nest 控制器上测试了性能,returns get 请求中的文本(无数据库)。 以及与 express 相同的简单 GET 控制器(中间件)。
我使用了 WRK 工具来测试性能。
因此,plain express 比 nestjs 快 2 倍。 为什么 nestjs 会产生如此多的开销?
更新 - 2020 年 3 月 17 日
我们现在 运行 为每个新 PR 设置基准。最新的基准之一可以在这里找到:https://github.com/nestjs/nest/runs/482105333
Req/sec Trans/sec
Nest-Express 15370 3.17MB
Nest-Fastify 30001 4.38MB
Express 17208 3.53MB
Fastify 33578 4.87MB
这意味着 Nest + FastifyAdapter
现在比 express 快 2 倍。
更新 - 2018 年 9 月 22 日
基准目录已添加到存储库:https://github.com/nestjs/nest/blob/master/benchmarks/all_output.txt(您也可以 运行 在您的计算机上进行基准测试)。
更新 - 24.06.2018
Nest v5.0.0
支持 fastify。 Fastify + Nest 集成甚至比普通(!)express 更高效。
下表显示了 Nest 与普通快速路由处理程序相比所做的事情:
- 它用 try..catch 块包围你的路由处理程序主体
- 它使每个路由处理程序
async
- 它创建一个全球快速路由器
- 它为每个控制器创建一个单独的路由器
- 它绑定错误处理中间件
- 它绑定
body-parser
中间件(json
和扩展urlencoded
)
所有提到的事情都反映了一个真实世界的例子(可能 99.9% 的快递应用程序也必须这样做,这是不可避免的)。这意味着如果你想比较 Express 和 Nest 的性能,你应该 至少 涵盖以上几点。与以下示例的比较:
app.get('/', (req, res, next) => res.status(200).send('Hello world'));
在这种情况下是不公平的,因为这还不够。当我涵盖这些要点时,这就是我收到的(表达 4.16.2):
Running 10s test @ http://localhost:3000
1024 connections
Stat Avg Stdev Max
Latency (ms) 225.67 109.97 762
Req/Sec 4560 1034.78 5335
Bytes/Sec 990 kB 226 kB 1.18 MB
46k requests in 10s, 9.8 MB read
另外,Nest 必须:
- 识别结果是否为 Promise/Observable/plain 值
- 根据结果类型,使用
send()
或json()
(+1条件) - 添加 3 个条件(
if
语句)来检查管道、拦截器和守卫
Nest (4.5.8) 有一个输出:
Running 10s test @ http://localhost:3000
1024 connections
Stat Avg Stdev Max
Latency (ms) 297.79 55.5 593
Req/Sec 3433.2 367.84 3649
Bytes/Sec 740 kB 81.9 kB 819 kB
34k requests in 10s, 7.41 MB read
这意味着 Nest 性能约为 79%(-21%)。这是由于上述原因,而且,因为 Nest 与 Node 6.11.x 兼容,这意味着它不能在幕后使用 async/await - 它必须使用生成器。
根据这些数据得出什么结论? None,因为我们不习惯创建只有 returns 没有任何异步内容的纯字符串的应用程序。与 Hello world
的比较没有任何意义,它只是一个花絮:)
PS。我使用了 autocannon
库 https://github.com/mcollina/autocannon
autocannon -c 1024 -t30 http://localhost:3000