Use llhttp through wasm

[ronag]

Would it be possible and make sense to use https://github.com/nodejs/llhttp instead of http-parser-js? Maybe as an opt-in?

[ronag]

The performance of http-parser-js came up as part of a discussion regarding this library. Hence this issue.

[mcollina]

I’d be happy to, however llhttp is not part of the public API, and I would prefer not to use a binary addon.

Wasm could be cool, but I do not know how it would perform. On top of of that, all of this inlines and it avoids one or more jump between the http parser (C) and client (JS). Tbh, I don’t expect a bump in speed, but I would be happy to be surprised.

[szmarczak]

I have to say I'm impressed. Even with http-parser-js it's still faster than the native Node.js http.

undici x 20,826 ops/sec ±1.70% (87 runs sampled)
Fastest is undici

Benchmark source code

'use strict';
const Benchmark = require('benchmark');
const {Client} = require('undici');

const suite = new Benchmark.Suite();

const client = new Client('https://localhost:8081', {
    tls: {
rejectUnauthorized: false
    }
});

const options = {
    path: '/',
    method: 'GET'
};

// Benchmarking
suite.add('undici', {
    defer: true,
    fn: async deferred => {
        const {body} = await client.request(options);
        body.resume();

        body.once('end', () => {
            deferred.resolve();
        });
    }
}).on('cycle', event => {
    console.log(String(event.target));
}).on('complete', function () {
    console.log(`Fastest is ${this.filter('fastest').map('name')}`);
}).run();

The fun fact is that it's even faster than the native HTTP2 implementation:

http2 x 16,172 ops/sec ±1.21% (85 runs sampled)
https - keepalive x 13,158 ops/sec ±2.88% (78 runs sampled)

[ronag]

Anyone of you know of anyone that might be interested in creating or helping out with a wasm build of llhttp that can be used as an alternative to http-parser-js? I hope it would not be too difficult if one is familiar with the wasm build flow.

[mcollina]

In would recommend to open an issue on https://github.com/nodejs/llhttp, there is also https://www.npmjs.com/package/llhttp which might be usable somehow?

[ronag]

@szmarczak Would you mind running those benchmarks again against master? I'm curious how much of a difference recent improvements have made.

EDIT: even better if you use request.stream #109

[szmarczak]

master: undici x 21,168 ops/sec ±2.00% (88 runs sampled)

[szmarczak]

#109 undici x 20,131 ops/sec ±1.81% (85 runs sampled)

but it very often goes below 20k: undici x 19,812 ops/sec ±2.01% (85 runs sampled)

[szmarczak]

ah wait I didn't use the newer API, lemme check it out

[szmarczak]

        client.stream(options, () => {
            const obj = {
                on: () => obj,
                write: () => {},
                end: () => deferred.resolve()
            };

            return obj;
        });

undici x 24,184 ops/sec ±1.64% (85 runs sampled)

        client.stream(options, () => {
            let buffered = '';

            const obj = {
                on: () => obj,
                write: chunk => {
                    buffered += chunk;
                },
                end: () => deferred.resolve()
            };

            return obj;
        });

undici x 23,080 ops/sec ±1.50% (83 runs sampled)

That's a big improvement!

[dnlup]

I did a quick test and the package https://www.npmjs.com/package/llhttp can be used directly, so it seems wasm is not necessary.
A lot of tests fail, I would like to dig deeper to check if it is something that can be solved by just refactoring or there are some major incompatibilities.

client-base

...
const { HTTP: HTTParser } = require('llhttp')
...

Note: I don't know how much this task would take atm

[dnlup]

After some research I found this issue which seems to suggest a way to use this parser through Node directly, which I think it could be a better option.

I did try those steps some time ago and faced the same errors.

@mcollina , when you say

I’d be happy to, however llhttp is not part of the public API,

You mean you wouldn't like to try the approach suggested in the issue?