Express: Performance Overhead

[ronag]

Has anyone looked into these numbers?

https://github.com/uWebSockets/uWebSockets/blob/master/images/wrk_benchmark.png

What's causing rather large overhead relative to non-wrapped NodeJS http?

[dougwilson]

Hi @ronag, do you know what code is being used for the comparison? At lease when benchmarks like this have come up in the past, they usually are the same thing: a simple server replying with hellow world or something.

Since Express is built on top of the Node.js http module, Express cannot be faster than than, but in the hello world kind of example, since Express adds so many features like sugar, ETags, query parsing, fressness, and more, Express will always be slower than the http server because... it does more stuff.

[ronag]

@dougwilson: Thanks for the reply! I am not sure exactly how the benchmark works. But the code seems to be located here, https://github.com/uWebSockets/uWebSockets/tree/master/benchmarks.

I was just a bit surprised by the significant performance gap and also a bit curious what parts (feature) of expressjs might be the cause for it.

https://github.com/uWebSockets/uWebSockets/issues/426

[dougwilson]

Nothing in that folder is using Express. As far as what is the difference: without understanding the benchmark I really cannot comment on it, since I don't know what it's doing. Based on previous benchmark questions, though, I shared above what the cause usually is for simplistic benchmarks. The TL;DR is that Express and the Node.js http module are not even comparable because they don't even provide the same functionality.

[alexhultman]

These are experimental results "not published yet" and the goal is not to replace Express but rather have Express run ontop of it. Experimental WIP

[wesleytodd]

I have looked into that project before, and it looks awesome. @alexhultman I would be interested in taking a look and maybe helping out with express compatibility if you need that kind of help. Is there a place for me to start looking?

[alexhultman]

Well I first have to release a version and even then it will most definitely take at least one more version release to get things compatible at all. I think Express compatibility is far in the future, but I want to get there at some point.

[wesleytodd]

How far different are your request and response objects? Because adding the ability for express to swap out http libs is trivial. And your create server seems compatible:

https://github.com/expressjs/express/blob/5.0/lib/application.js#L602-L603
https://github.com/uWebSockets/uWebSockets/blob/master/nodejs/http.js#L5

Even if you think it is far out, I would be willing to take a look if pointed in the right direction. If you want I can open an issue on your repo for discussion.

[alexhultman]

I still don't know, I just got pipelined respones working this night and I just finished some benchmarking of different solutions to handle aborted responses (still not implemented, will crash if responding to aborted response - that kind of experimental). It's still completely broken and experimental. You can open an issue to track the progress, sure.

[dougwilson]

Regardless, @ronag it is not possible for us to comment on the differences without understand what is being tested. The text written on the uws module page says:

[...] while ExpressJS wraps Node.js and performs 3x worse than Node.js. [...] Roughly speaking, the fewer NPM modules you can use the better.

This is a very true statement: if you do nothing, then you'll be faster. For example, the reason Express is slower than what is wraps is because of all the out-of-the-box features you don't have to write. If you're happy with the OOB features of the Node.js implementation, of course use it, though by the time you write an entire app by hand reinventing everything Express and it's ecosystem gives you, I guess you'll feel better in some way :)

A bunch of the features Express provides on by default you can certainly turn off to reclaim some performance if you're happy without those features.

[dougwilson]

Also on that note, as mentioned by @wesleytodd , I'm sure that we can figure out how to get Express to run on top of the uws HTTP interface. We want to focus on the value added on top of the raw HTTP parsing / marshaling stuff to help improve productivity, so in the end what HTTP server Express runs on top doesn't even matter :) so if we can place it on top of uws for a performance boost, then that's great.