Working Group Charter

[wesleytodd]

We need to outline the goals, scope, and membership guide. I can pull from the other WG's for some of the language, but we need to define the goals for the WG for sure. Here are the things I was thinking we can seed the conversation with:

1. Performance monitoring tooling

We do not have infra for testing performance consistently within any of the repos. I think we should have tooling to do three types of performance work:

1. Narrowly scoped benchmarks. You may call this "micro-benchmarks" but I hesitate to use that term because they can often be used to justify bad overall perf decisions. That said, we do need to be able to test a single library method from version to version to test a specific optimization/change.
2. Benchmark suite's on PRs (on demand or automated). These would be library specific benchmarks which give a general signal if we had a perf regression or if a PR's goals is perf related. These should be general enough (and fast to run) that we can run them regularly and cheaply.
3. Comprehensive HTTP benchmarks. This is the more involved item, but to avoid the trap of micro-benchmarks and to track "real world" performance, we need to have benchmarks which exercise the e2e performance for the framework.

My goal would be that we share some agreement on approach to these in this group, and work with individual repo captains on how they apply/work within each repo individually. An example of how I see this working:

The router repo has a PR which intends to improve performance of routing. We should first test out the change with type 1 and 2 benchmarks. Once those are showing good signs, we should be able to kick off automation to run an HTTP benchmark on express with that router PR integrated (without merging).

And then ideally this WG would maintain and support those tools long term for the project. Including managing any cloud infra or GHA workflows involved.

2. Performance optimization work

The obvious outcome of this is actual work to improve the perf of all libs and the express package. This group does not need to drive that work, but would be here if there were discussions to have that cross many repos or where folks with performance experience can be found to consult.

That said, I was thinking this would be a great way to organize and prioritize the work we want to land this next year. We have a bunch of low hanging fruit, but also some with major UX/api impact that we will need to discuss. My hope is this group will be able to tackle those topics which we never seem to get to on the TC and working session times. Focus and finish on some of these items!

3. Working with Node.js core on unlocking core perf improvements

One of my initial drivers in being involved in reviving the project is how it was blocking critical improvements in Node.js core. I think there is a lot of opportunity here to make changes in express and our packages which make landing those optimizations in Node.js much easier. I would like to see us partner with the @nodejs/web-server-frameworks group to figure out where to put our effor here. While some of this is not 100% performance related, I think this group will be the best place to start because it has been too hard to organize the larger conversation on this. Focusing on the perf aspects should help us pick some individual changes to focus on.

---

Obviously this does not cover everything, but I hope this at least helps folks start having conversations about what we want the charter to look like.

[bjohansebas]

I would like to see us partner with the @nodejs/web-server-frameworks group to figure out where to put our effor here.

there's also a kind of subgroup within the web-server-frameworks group working on a future version of HTTP, and I intend to contribute both with code and by structuring it to make Express and Node.js even faster (https://github.com/nodejs/http-next)

[wesleytodd]

One thing that has been on my mind here is that this work should be "short term" in that once the process and standards are in place, and once the initial round of perf changes are landed, we should be able to spin down the WG. I see this as something that we do for the next 2 years or so, then it should be well enough established that each set of Captains are in charge of keeping things going from there. Just wanted to call that out here since I had not yet.

[andrehrferreira]

Hi guys, I have been using the testing approach using the project https://github.com/fastify/benchmarks/ I believe it is a good basis for testing and comparisons, and I use the Node Inspector to analyze the process itself in more depth, that's how I found the functions with performance problems, if you have other interesting tools I would like to test =)

[wesleytodd]

@andrehrferreira, can we move this comment to #12 or maybe #13? The charter will be more about the goals and keeping track of what work is happening. #12 is more about which types of tests we will do and #13 is more specific for us to pick some tools to recommend across the project (and maybe invest in tooling for).

[andrehrferreira]

@wesleytodd Of course

[cesco69]

There are some well-known public benchmarks comparing Express with other Node.js web servers. However, some implementations of Express used in these benchmarks are outdated — they rely on old versions of Node.js and Express itself, which results in unfairly poor performance outcomes.

I believe the Perf Working Group could help maintain and update these benchmarks to better reflect Express's actual performance and promote more accurate results.

Here are some of the benchmarks I’m referring to:

• https://www.techempower.com/benchmarks/
• https://web-frameworks-benchmark.netlify.app/
• https://github.com/SaltyAom/bun-http-framework-benchmark

[wesleytodd]

@cesco69 Would you mind creating an issue for this idea specifically? Next week I am going to try and turn this into a PR, and while I agree this feels like it can be in scope I want to make sure we have a discussion about it before including it in the charter directly. If it is in a separate issue we can do that but also close this when we open the PR.

[cesco69]

@cesco69 Would you mind creating an issue for this idea specifically? Next week I am going to try and turn this into a PR, and while I agree this feels like it can be in scope I want to make sure we have a discussion about it before including it in the charter directly. If it is in a separate issue we can do that but also close this when we open the PR.

done #21