I've just tested performance on a simple nest's controller, that returns text on a get request (no database). And the same simple GET controller (middleware) with express.
I used WRK tool to test performance.
And as a result plain express is 2 x times faster than nestjs. Why is so much overhead created by nestjs?
Fastify provides a good alternative framework for Nest because it solves design issues in a similar manner to Express. However, fastify is much faster than Express, achieving almost two times better benchmarks results. A fair question is why does Nest use Express as the default HTTP provider?
Since ExpressJS doesn't follow MVC, there's no proper structure which makes the application inefficient and less optimized. NestJS becomes a better choice for developers as it is clearly based on an architecture with components like modules, controllers, and providers.
It seems that Node. js with 35.5K GitHub stars and 7.78K forks on GitHub has more adoption than NestJS with 17.4K GitHub stars and 1.22K GitHub forks. According to the StackShare community, Node.
The Nest framework is built using TypeScript which allows developers to build highly scalable and testable applications. Built on top of Express.
UPDATE - 17.03.2020
We are now running benchmarks for every new PR. One of the latest benchmarks can be found here: 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
That means Nest + FastifyAdapter
is now almost 2 times faster than express.
UPDATE - 22.09.2018
Benchmarks directory has been added to the repository: https://github.com/nestjs/nest/blob/master/benchmarks/all_output.txt (you can run benchmarks on your machine as well).
UPDATE - 24.06.2018
Nest v5.0.0
supports fastify. Fastify + Nest integration is even more performant than plain(!) express.
The following list shows what Nest is doing in comparison to plain express route handler:
async
body-parser
middleware (both json
and extended urlencoded
)All of the mentioned things reflect a real-world example (probably 99.9% express apps have to do this as well, it's unavoidable). It means that if you want to compare Express and Nest performance, you should at least cover above points. The comparison with the example below:
app.get('/', (req, res, next) => res.status(200).send('Hello world'));
Is unfair in this case, because it's not enough. When I cover these points, this is what I received (express 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
Additionally, Nest has to:
send()
or json()
(+1 condition)if
statements) to check pipes, interceptors and guardsThere's an output for 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
This implies that Nest performance is around 79% express (-21%). This is due to the reasons set out above, and moreover, because Nest is compatible with Node 6.11.x which means that it can't use async/await under the hood - it has to use generators.
Which conclusion is to be drawn based on those stats? None, because we aren't used to creating applications that only returns plain strings without any asynchronous stuff. The comparisons with Hello world
means nothing, it's only a titbit :)
PS. I used autocannon
library https://github.com/mcollina/autocannon
autocannon -c 1024 -t30 http://localhost:3000
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With