Make Express faster! Let's improve our benchmarks ⚡

[andrehrferreira]

Hello everyone, I am performing a performance test between several http servers in node.js and I noticed that Express is performing much lower than the others, due to the fact that I use Express in practically all my projects. I would like to know if there are already people collaborating in improving the performance of the project, if not, would you like to start studies to improve these results?, since in my opinion Express is the most relevant and used among all, below are the test results, and the script I sent via pull request.

(index)	Framework	Requests/sec	Transfer/sec	Latency	Total Requests	Transfer Total	Latency Stdev	Latency Max
0	cluster_fastify	138457.36	23.24MB	15.58ms	1388733	233.09MB	58.10ms	842.11ms
1	cluster_http	137054.68	23.27MB	14.56ms	1376920	233.74MB	52.84ms	802.10ms
2	cluster_koa	122922.41	20.51MB	14.97ms	1234474	206.03MB	52.39ms	823.15ms
3	cluster_hapi	94445.64	19.91MB	23.66ms	949082	200.03MB	83.97ms	1.10s
4	cluster_restify	93398.96	16.48MB	22.78ms	937893	165.47MB	79.86ms	1.09s
5	cluster_express	43577.99	9.89MB	60.64ms	437738	99.36MB	190.66ms	2.00s
6	single_uws	37081.93	3.71MB	27.45ms	372355	37.29MB	3.06ms	76.40ms
7	cluster_uws	35629.39	3.57MB	28.57ms	357699	35.82MB	1.82ms	95.33ms
8	single_http	24159.04	4.10MB	42.09ms	242998	41.25MB	7.12ms	235.08ms
9	single_fastify	23794.91	3.99MB	43.18ms	239197	40.15MB	11.90ms	343.66ms
10	single_koa	20263.96	3.38MB	50.25ms	204371	34.11MB	17.65ms	294.61ms
11	single_hapi	14163.93	2.99MB	71.82ms	142853	30.11MB	16.06ms	410.62ms
12	single_restify	14036.58	2.48MB	72.46ms	141118	24.90MB	13.49ms	527.51ms
13	single_express	6830.47	1.55MB	147.89ms	68993	15.66MB	29.75ms	626.75ms

The tests were performed on Ubuntu 20.04.6 LTS via WSL 2 on Windows 10, my computer configuration is an Intel Core i9 10980 XE, 256 GB of DDR4 ram, 2TB nvme EVO pro SSD, NVidia Asus Rog RTX 3080 TI, Node v18.16.1

[UlisesGascon]

Hi @andrehrferreira,

Thanks for bringing this topic up. I'll transfer this issue to the discussions repo for better visibility.

Right now, our main focus is on Express@5, which we believe will be faster than Express@4 due to the significant changes we've introduced.

That said, our current benchmarks still need improvement. Our plan is to concentrate on comparing different Express releases rather than benchmarking against other projects. Fastify, for example, already provides great comparison tool: https://fastify.dev/benchmarks/ (https://github.com/fastify/benchmarks/).

After we release v5, we can shift our efforts towards further optimizing Express. In the meantime, we could add more test cases and include benchmarks for our direct dependencies, such as body-parser.

Is this something you'd be interested in working on?

[andrehrferreira]

Hi @UlisesGascon

Of course I can help, just tell me what types of tests you think are interesting to optimize the performance of the packages that I eventually work on implementing. I currently work on developing multiplayer game servers, so I end up performing a lot of performance tests both at the protocol level and in applications and languages, so it would be a pleasure to help with whatever is needed.

[wesleytodd]

Related: #306

Just posting to add that link, once I am caught up on the notifications I am going to circle back on that proposal and start putting together some plans on how we should approach this problem.

[andrehrferreira]

Hey guys, how are you?

I took some time off to take a year-end break, I recently performed some tests using my integration tool with the Node.js inspector, I'll leave the link to the test repository, https://github.com/andrehrferreira/express-benchmarks, the test is very simple, I uploaded an instance of express without any middleware and performed the monitoring using the inspector, then I used autocannon to trigger multiple requests in this application using the command autocannon -c 100 -d 40 -p 10 localhost:3000

As a result, my system creates a cpuprofile file that I analyze using the application https://discoveryjs.github.io/cpupro, I'll leave the profile file in the repository for deeper analysis, but basically, 37.5% of the processing time was from internal express functions, with 13.8% from response.js and 9% from the router, which in my opinion are the main ones bottlenecks of the current version, 7.3% in middleware/init.js, looking deeper the most worrying is in fact the send function for response, followed by the header and contentType, as I had already commented before in my point of view the main problem is in the use of Object.defineProperty, however I will continue analyzing other important points to be optimized