[Node.js]: Support turbo-http

[qti3e]

This addresses: #308

As described in my commit message, I've faced some issues when I wanted to use clusters, and I'm almost sure I haven't got this errors when I was trying the same things a bit earlier

[waghanza]

Thanks for your contributions

However, the framework behind is rayo

I think we better have to create a micro-benchmark, choosing the fastest implementation between

• turbo-http
• @rayo/storm
• raw clustering
• pm2

what do you think ?

[aichholzer]

Thank you for this @qti3e -As soon as I have a minute I will look into your PR. Sorry, this might not be in the next couple of days as I am moving to another city and I have a whole house to pack.

[aichholzer]

@qti3e -Just note that there is not clustering going on here. Not sure this was intentional or not, just double checking.

[waghanza]

@aichholzer As I understand, the framework used here is rayo, turbo is the library replacing node default http server , right ?

EDIT : polka not rayo

[aichholzer]

@waghanza

As I understand, the framework used here is ~rayo~ polka, turbo is the library replacing node default http server , right ?

Correct. Does not make any difference though.

[waghanza]

@aichholzer in fact, I've noticed this to say that we should use node/polka instead of node/turbo, just in term of design :stuck_out_tongue: -> e.g : having tree as language/framework

[qti3e]

@aichholzer Based on how Node.js cluster module works, it's not theoretically possible to have clustering with turbo-http, but I'm not really sure how I did that before on the issue, I remember exactly getting 6x speed up :/

[qti3e]

@waghanza You already have a bench for node/polka, and it shows polka is the fastest framework, based on that I used turbo-HTTP which is a replacement for Node's internal http module beside polka, only because it's the fastest framework and can demonstrate the real power behind turbo.

We can use turbo with almost all of the frameworks in /node dir.

[waghanza]

@qti3e in fact, I think (in order to prevent a messy project) to have one implementation of each framework (turbo is not a framework) that's why I propose to test each actuall implementations using turbo / pm2 ... and choose the fastest one @aichholzer What do you think ?

[aichholzer]

@qti3e -You can cluster turbo-http like I explained here.

@waghanza -Correct. turbo-http is not a framework, it is a replacement for Node's native http. Comparing turbo-http with any other framework is like comparing apples to oranges. Our focus here are frameworks that use native functionality. @qti3e one framework over another, using native functionality, can still have big impact. Compare, rayo with express for example, both native but rayo twice as fast. 👏

@qti3e -Don't get me/us wrong, but your PR should be in a different category altogether, based on what @waghanza wrote last.

[waghanza]

@qti3e if you mind, I can adjust your PR

@aichholzer You'right, our goal is to compare frameworks, at least it was @tbrand motivation when creating this project.

however this assumption is not exactly the same as mine, but not so-far

Our focus here are frameworks that use native functionality

it just that I have not native functionality in mind

for me what we want to test is what developer will use (with a focus of performance, no matter is this is native or not)

[aichholzer]

@waghanza -I meant, for example, compare Node with Node stuff (native), not Node with C/C++ (not native). There is space for comparing everything but not everything under the same hood.

IMHO, of course.

[waghanza]

@aichholzer good point :tada: but where we will put @qti3e contribution, then ?

[qti3e]

@waghanza @aichholzer I understand your point of view, feel free to close this PR : )

[waghanza]

@qti3e surely not 😃 any contribution has to be valued

[waghanza]

@aichholzer I propose to take @qti3e but not to show result, by default

You're right, the more valuable is to display native (I say default but it is just wording), but experimental (what tfb consider as platform) are valuable (for some devs)

We could labelize the work done in this PR as experimental and not display them by default (and allow a filter in UI later or cli option when using cli)

@tbrand What do you think ?

[waghanza]

@aichholzer and we can also test https://github.com/denoland/deno

[qti3e]

@waghanza Net API is not implemented in Deno yet, and it will take weeks to see a stable HTTP API in Deno.

[waghanza]

@qti3e good to know

[waghanza]

With the work done in https://github.com/the-benchmarker/web-frameworks/pull/317, this is easy to set-up (the PR add FRAMEWORK.yml <- a config file parse to list framework)

[waghanza]

@qti3e @aichholzer Comparing this implementation with all node here, I found (req/s) :

Language (Runtime)	Framework (Middleware)	Requests / s	Throughput
node	rayo (1.2)	60859.33	91.08 MB
node	polka (0.5)	60269.00	90.29 MB
node	fastify (1.12)	51334.00	125.43 MB
node	koa (2.5)	40500.67	85.66 MB
node	express (4.16)	37700.00	92.27 MB
node	restify (7.2)	32587.67	57.19 MB
node	turbo_polka (0.3)	25724.33	24.11 MB
node	hapi (17.6)	23787.00	61.52 MB

polka is less performant with turbo, strange no ?

And in term of latency I have

Language (Runtime)	Framework (Middleware)	Average	50th percentile	90th percentile	99th percentile	99.9th percentile	Standard deviation
node	polka (0.5)	21.53 ms	13.53 ms	31.70 ms	186.03 ms	871.36 ms	44721.67
node	rayo (1.2)	22.17 ms	13.54 ms	30.51 ms	240.83 ms	869.55 ms	47735.00
node	fastify (1.12)	27.10 ms	16.34 ms	36.61 ms	314.06 ms	1007.27 ms	59102.33
node	koa (2.5)	30.75 ms	20.40 ms	46.09 ms	269.38 ms	1082.10 ms	55766.00
node	express (4.16)	36.31 ms	21.67 ms	49.61 ms	418.70 ms	1257.13 ms	76703.00
node	restify (7.2)	34.12 ms	26.11 ms	55.03 ms	150.06 ms	764.93 ms	37356.00
node	hapi (17.6)	79.78 ms	36.73 ms	79.73 ms	1254.36 ms	2501.65 ms	209134.67
node	turbo_polka (0.3)	39.23 ms	37.80 ms	42.87 ms	72.08 ms	549.93 ms	20761.33