2025-06-11 Express Performance Working Group Meeting

[github-actions]

Date/Time

Timezone	Date/Time
America/Los_Angeles	Wed 11-Jun-2025 08:00 (08:00 AM)
America/Denver	Wed 11-Jun-2025 09:00 (09:00 AM)
America/Chicago	Wed 11-Jun-2025 10:00 (10:00 AM)
America/New_York	Wed 11-Jun-2025 11:00 (11:00 AM)
Europe/London	Wed 11-Jun-2025 16:00 (04:00 PM)
Europe/Amsterdam	Wed 11-Jun-2025 17:00 (05:00 PM)
Europe/Moscow	Wed 11-Jun-2025 18:00 (06:00 PM)
Asia/Kolkata	Wed 11-Jun-2025 20:30 (08:30 PM)
Asia/Shanghai	Wed 11-Jun-2025 23:00 (11:00 PM)
Asia/Tokyo	Thu 12-Jun-2025 00:00 (12:00 AM)
Australia/Sydney	Thu 12-Jun-2025 01:00 (01:00 AM)

Or in your local time:

• https://www.timeanddate.com/worldclock/?iso=2025-06-11T15:00:00

Agenda

Extracted from perf-wg-agenda labelled issues and pull requests from expressjs/perf-wg prior to the meeting.

• Working Group Charter #3
• Discussion collaboration with NodeSource
• @wesleytodd to present a plan for load testing and performance debugging tools (I will have the issue up on monday hopefully)
• Discuss plans for benchmarking

Links

• Minutes:

Joining the meeting

• link for participants: https://zoom-lfx.platform.linuxfoundation.org/meeting/96601939832?password=ffe66d99-9a98-402a-bef7-c1ab962dbe58
• For those who just want to watch:

[jonchurch]

Some notes from my takeaways:

What We're Here to Do

One of the most valuable things the perf wg can do is offer a framework for evaluaating performance changes. (both over time, and proposd changes).

We are not focused on telling contributors how to write faster code. We are focused on defining how express evaluates performance work, how we measure whether a change is meaningful and how we measure perf related PRs are evaluated consistently and in context

How We Can Do This

• Creating evaluation criteria (latency, throughput, memory, etc)
• Providing tooling and environments to make measurements possible
• Help contributors run perf tests and interpret results

We plan to split perf tests into two categories, focused unit benchmarks living in package repos and e2e load tests of realistic application code living in express for top level deps and express itself.

Next Steps

We have some patches, and we have some questions we want to answer. e.g. #15

We can work on the code Wes scaffolded here #18 to start trying to answer some questions.

We haven't decided which questions we need to ask, but here's a start (and Im sure that thread has plenty of questions):

Does this proposed change meaningfully improve performance under realistic load?
By how much? (p95 latency? req/sec? CPU usage?)
Under what conditions? (concurrency level, payload size, middleware stack)