4 ms·

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 co

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 7y ago
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 7y ago
  Submit that to them then?
  - spion 7y ago
    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 7y ago
      Maybe we'll have to disagree because I'm still pretty sure nodejs is somehow slow.
      - spion 7y ago
        You don't have to trust me, here is a diff you can apply of the work I did: https://gist.github.com/spion/2779ae6dc9552c229c1eeacd90c03bf3 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

spion 7y ago

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 7y ago
Submit that to them then?
- spion 7y ago
  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 7y ago
    Maybe we'll have to disagree because I'm still pretty sure nodejs is somehow slow.
    - spion 7y ago
      You don't have to trust me, here is a diff you can apply of the work I did: https://gist.github.com/spion/2779ae6dc9552c229c1eeacd90c03bf3 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