[staticassertion]

I think your point is actually just proving something important that I ended my initial post with - that there is almost never a "pure IO" workload, but that compute is actually an extremely important part of any service. Given node's concurrency model it's even more important, as compute can block other operations.

[spion]

I had another glance at the framework benchmark, and the quality is absolutely dreadful

I removed the unnecessary middleware bloat (pug html renderer middleware for an API server, really? body-parser and form parser even for endpoints where it's not being used?) and switched to standard pg instead of pg-promise (standard pg also supports promises, pg-promise hasn't been needed for quite a while now)

The performance went from 600req/s to 5500 req/s on the db benchmark, 9x improvement with 10 minutes of work. I think thats a pretty damning result for the tech-empower framework benchmarks quality, at least when it comes to node. This is just standard libraries and practices, not even hacks like replacing the built in url parser with fast-url-parser.

[staticassertion]

Submit that to them then?

[spion]

It might be a good idea, although I fear that if I only fix one node framework and keep the rest intact it will create a false impression that that framework is somehow amazing.

Still better than a false impression that nodejs is somehow slow.

They really need some QC though.

[staticassertion]

Maybe we'll have to disagree because I'm still pretty sure nodejs is somehow slow.

[spion]

You don't have to trust me, here is a diff you can apply of the work I did: https://gist.github.com/spion/2779ae6dc9552c229c1eeacd90c03b...

you can run ./tfb --test express-postgres and compare.

If you can't wait for all the tests to complete, a representative one can be obtained more quickly by running

./tfb --test express-postgres --type db --query-levels 10 --concurrency-levels 128