-
Notifications
You must be signed in to change notification settings - Fork 17
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat(adr): establish a performance working group #306
base: master
Are you sure you want to change the base?
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
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 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, |
Hey @andrehrferreira, thanks for the post. These kinds of things are great, but for the project the larger problem is two fold:
It has been my experience that many engineers will spend a lot of time on optimizing some small subsystem that has little to no impact on the real world performance of their applications. My goal with setting up this working group is to level up everyone who wants to do perf work and to give ourselves the tools to do the right analysis for the right type of changes. Please keep finding things, and preferably open PRs with a change, a before and after benchmark result, and a description of how that impacts real applications (is it hot path, startup, etc), but also lets post that in the applicable repos instead of here where we are bootstraping the WG. Thanks! Onto the topic of the WG, I am going to be just starting the work on this next week. I am going to update this proposal soon to include some more detailed goals/outcomes so we can be clear on what this is for. |
@wesleytodd, How are you? When I opened this discussion a few months ago, I was at the beginning of a project I'm working on. Due to the understandable long period that Express requires to upload updates of this size, I ended up rewriting all the functions in parallel in a separate project that I'm already using in the application. I'll leave the repository here https://github.com/cmmvio/cmmv-server In addition to the Express codes, I used part of The third, relatively minor problem is the middleware processing lifecycle, which Fastify solved it using Hooks, and that was the path I followed as well. Below I will leave the numbers from the last performance test I did: Benchmarks
|
I just pushed some updates to the proposal. Adding the TC for a review now that it has more details. |
Co-authored-by: Sebastian Beltran <bjohansebas@gmail.com>
@@ -0,0 +1,71 @@ | |||
# ADR [Number]: Performance Working Group |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Don't forget to add the number before merging
This proposal would create a Performance Working Group. See the RFC content for details.
NOTE: this WG would operate under the STF proposal we have made. More details on that to come as we work through the process with the German Govt.