EFI: Performance

[sheplu]

Motivation

Performance is key, even more today when all the users want something quickly. But the first step is to be aware of said performance, monitor it and know if we increase or decrease the overhead when compared to the base runtime.
Performance is also a matter of size, and being able to ship packages with a lower footprint can help with startup time (or cold start).

Expectation

Include performance as part of the development and publish process

Implementation

Implement a workflow to alert if a package is too heavy or grow to much on a PR
Include benchmark and performance testing as part of all repositories
Create a separated benchmarck repo that would test new releases against some use cases, and compare against base Node.js

Status

Part: Organization
Status

• workflow for size:
• benchmark on repositories
• standard application benchmark

Draft

As the largest framework used, performance is key to the adoption of the framework, but as the full ecosystem relies on modules part of the Express organization, we have to provide the best performance for our libraries.
To ensure that we are moving in the right direction, all packages should be monitored for performance using benchmarks. The Express ecosystem is used across multiple use case, but it is definitely handling application under heavy load and packages should be tested against this kind of use case, while also handling specific benchmark tests (for example Cold Start)

[wesleytodd]

I think this one is under the larger umbrella of documenting the projects technical priorities right? I feel like a similar doc to Node's would be good. And it likely should cover much more than just the approach to performance.

[UlisesGascon]

This is a great initiative! I think currently we have some basic performance testing (see: expressjs/express#5312), but we can ask for support from the community on this (there are many potential good first issues). Time ago I started with a very basic and rough perf version comparator.

I will strongly suggest to avoid comparing Express with other frameworks, just to avoid the typical social media flame/drama. We can focus on comparing new changes against previous versions (as Node.js does) or even compare Express against Node.js core libraries to see how our deviation increase/decrease

[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

[wesleytodd]

Awesome @andrehrferreira! You might be interested in this which I will be kicking off pretty soon: #306

[andrehrferreira]

@wesleytodd I will follow this topic