Add HTTP body reader helper

[BV-WebDev]

To parse the request body, we currently have to use the "onData" function.
While it provides full control over the receiving stream and works well for uploading or client-side streaming, it is overly complicated and less efficient for simpler requests such as form post or json api.

So i propose adding an "onFullData" function that automatically concatenates the received chunks and returns the complete body as an ArrayBuffer to Node.js. The performance benefits:

• Only one call from c++ to Node.js
• No buffer copying and concatenation on the Node.js side

Function signature could be:
onFullData(maxSize: number, timeout: number, handler: (fullBody: ArrayBuffer) => void) : HttpResponse;
On timed out or max size exceeded, handler returns with the partial body.

[uNetworkingAB]

I have missed this message. Anyways, I have added experimental support for this now, you can try latest binaries with latest commit.

[Guthib-of-Dan]

I am sorry for seeming to be weird and having deleted message. Actually, I haven’t got used to discussions in GitHub + rushed a bit.

[BV-WebDev]

I benchmarked on windows.
Test code:

import uWS from "./uwsmaster/src/uws.js";

const port = 9001;

const onAborted = () => {
    console.log('Aborted');
};

const onFullBuffer = (res, buffer) => {
    //try { JSON.parse(buffer); } catch (e) { res.close(); return; }
    //buffer.toString();
    buffer.byteLength;
    res.end('OK');
};

const app = uWS./*SSL*/App({
    key_file_name: 'misc/key.pem',
    cert_file_name: 'misc/cert.pem',
    passphrase: '1234'
}).post('/nbchunk', (res, req) => {
    readNbChunk(res, (nb) => { console.log(nb); res.end(nb.toString()); });
    res.onAborted(onAborted);

}).post('/base', (res, req) => {
    readBodyBase(res, (buffer) => onFullBuffer(res, buffer));
    res.onAborted(onAborted);

}).post('/concat', (res, req) => {
    readBodyConcat(res, (buffer) => onFullBuffer(res, buffer));
    res.onAborted(onAborted);

}).post('/allocated', (res, req) => {
    readBodyAllocated(res, (buffer) => onFullBuffer(res, buffer));
    res.onAborted(onAborted);

}).post('/fullData', (res, req) => {
    res.onFullData(50000000, (ab) => onFullBuffer(res, Buffer.from(ab)));
    res.onAborted(onAborted);

}).listen(port, (token) => {
    if (token) {
        console.log('Listening to port ' + port);
    } else {
        console.log('Failed to listen to port ' + port);
    }
});

function readNbChunk(res, cb) {
    let nb = 0;
    res.onData((ab, isLast) => {
        nb ++;
        if (isLast) cb(nb);
    });
}

function readBodyBase(res, cb) {
    let buffer;
    /* Register data cb */
    res.onData((ab, isLast) => {
        let chunk = Buffer.from(ab);
        if (isLast) {
            cb(buffer ? Buffer.concat([buffer, chunk]) : chunk);
        } else if (buffer) {
            buffer = Buffer.concat([buffer, chunk]);
        } else {
            buffer = Buffer.concat([chunk]);
        }
    });
}

function readBodyConcat(res, cb) {
    let buffers, totalSize;
    /* Register data cb */
    res.onData((ab, isLast) => {
        const chunk = Buffer.from(ab);
        if (isLast) {
            cb(buffers ? Buffer.concat([...buffers, chunk], totalSize + ab.byteLength) : chunk);
        } else if (buffers) {
            buffers.push(Buffer.from(chunk))
            totalSize += ab.byteLength;
        } else {
            buffers = [Buffer.from(chunk)];
            totalSize = ab.byteLength;
        }
    });
}

function readBodyAllocated(res, cb) {
    let buffer, offset;
    /* Register data cb */
    res.onData((ab, isLast) => {
        const chunk = Buffer.from(ab);
        if (isLast) {
            cb(buffer ? buffer.fill(chunk, offset, offset + ab.byteLength) : chunk);
        } else if (buffer) {
            buffer.fill(chunk, offset, offset += ab.byteLength);
        } else {
            buffer = Buffer.allocUnsafe(Number(res.maxRemainingBodyLength()));
            buffer.fill(chunk, 0, offset = ab.byteLength);
        }
    });
}

Used body size: 5MB (11 chunk)

Concat on every call (/base)
JSON: 41 Req/Sec
STR: 80 Req/Sec
RAW: 112 Req/Sec

Concat on final call (/concat)
JSON: 52 Req/Sec
STR: 140 Req/Sec
RAW: 259 Req/Sec

Pre allocated buffer (/allocated)
JSON: 53 Req/Sec
STR: 152 Req/Sec
RAW: 320 Req/Sec

onFullData function (/fullData)
JSON: 53 Req/Sec
STR: 155 Req/Sec
RAW: 326 Req/Sec

[BV-WebDev]

We can already see there is a good gain with multiple chunks.
Once the OnFullData code is cleaned up and optimized, I will update the results.
Testing these takes time.

Please tell me what would be best to use.
Input: what body size should be tested?
Output: raw buffer, .toString, or JSON.parse?

[uNetworkingAB]

I spammed tiny JSON objects over POST and I get slightly better with onFullData than the JsonPost example but it is insignificantly so (not enough to say it is faster, and it shouldn't really be). At least onFullData does not have worse perf. for small data.

But this kind of brings me to the facepalm climax:

While we can deliver ArrayBuffer of JSON to the script very fast over HTTP, the tiny script step Buffer.from(ArrayBuffer) already cuts off 20% of total server performance. And if you then JSON.parse that Buffer (view) you cut off another 20% of total perf. By just parsing a tiny JSON in JS, you already lost 50% of all server perf. Parsing a tiny JSON is algorithmically "free" and should have zero measurable cost. But in JS, there is a 50% total server performance penalty. Because why not.

So we have kind of come back to square 1: nothing matters in JS because as soon as you do anything of slightest caliber, you basically negate all prior work and just default to standard apathy.

[Guthib-of-Dan]

Logically, onFullData is a function, which buffers data in memory, so testing it for something larger than 1mb might not be necessary, as many concurrent requests can make it a catastrophe. Larger requests are multipart-alike, but we can stream those to disk.
Devs usually expect json for whole-body requests, but if we compare onFullData with onData, raw buffer tells us more.

[uasan]

So we have kind of come back to square 1: nothing matters in JS because as soon as you do anything of slightest caliber, you basically negate all prior work and just default to standard apathy.

These improvements matter, even if they represent a tiny percentage of the overall JS runtime. You're giving a tool to those who are trying to make the JS runtime as productive as possible, and you're giving a tool to those who can't write effective onData handlers. That's why the helper really helps.

[BV-WebDev]

So we have kind of come back to square 1: nothing matters in JS because as soon as you do anything of slightest caliber, you basically negate all prior work and just default to standard apathy.

True, JS is not very fast.
But losing 50% of performance by parsing JSON is not what matters.
The point is that this server is faster than other JavaScript servers.
And that onFullData will give you a 0% to 7% improvement in parsing that JSON, depending on the number of chunks.

[uNetworkingAB]

The thing is I could easily make an entirely different JSON parser that works entirely different and basically takes ArrayBuffer, Query and an output buffer. Then you give it basically a "query language" like "[root.a, root.a.b]" then you access the extracted properties as offsets in the output buffer. This would make it essentially free of cost and be faster than any other JSON parser for JS. It would have zero memory allocaations and just give you pointer offsets in the input data (zero copy). It would be basically infinitely faster than JSON.parse that returns a dynamic garbage collected object of string keys copied (holy shit, that sentence makes me puke).

Then it would get hype, people would say, nice module it is so fast... but it has a complex interface can we make it return a garbage collected object instead? And then someone wraps it like that, making it worse than JSON.parse that also returns a garbage collected object and now we have negated the entire endeavour and we're back to square 1 where brainlets and hype always erode peak to lowest common denominator.

That's basically the summary of uWS.js itself, just on a smaller (imaginary) project. The idea immediately dies because I can already see the end result become as shitty as everything else already is.

[BV-WebDev]

That's the summary of programming itself, otherwise we would all be developing in assembly.

[Guthib-of-Dan]

By the way, why does "onFullData" rewrite "res->onAborted" call? I guess it is not a pub/sub system, so only one callback is valid. So it rewrites res.onAborted from js

[uNetworkingAB]

So to summarize:
For regular asynchronous requests we call onAborted().
For requests where we want to read the body we call onStream().
onData() remains but got deprecated.

No. This is not right.

onStream (optionally) replaced BOTH onAborted AND onData. "Stream events" are BOTH "Stream reset" and/or "Stream data". It's literally events regarding the stream.

[BV-WebDev]

Even for regular asynchronous requests we use onStream()?
So we do something like?:

res.onStream((chunk) => {
    if (chunk) return; // We don't care
    // Regular onAborted handler
});

[uNetworkingAB]

Yes. But I haven't even made a release yet. And interface is still not fully decided.

[uNetworkingAB]

Alternatively a variant of onData is added. None of this is set in stone I am experimenting

[uNetworkingAB]

onWritable, onAborted, onData -> the onData is known to be sub-optimal with isLast so maybe just another variant of onData.

[BV-WebDev]

I updated the results again.
With the addition of maxRemainingBodyLength() performing the preallocated body accumulation in JS is nearly the same performance as onFullData() (only +0.2%/chunk). So in the end the helper function may not be needed. We could just update the JSON example and call it a day.
onFullData still adds benefits (a bit faster, simpler, integrated maxLength), so it's your choice.

[Guthib-of-Dan]

There is one more possible improvement, but that needs new (or extended old) functionality. This idea is currently in process of being proposed to TC39, but demonstration tests already show benefits.
I am talking about detaching arrayBuffers. Doing it in C++ after onData callback is slower than detaching manually inside the callback. Same likely with websockets.
I still need to write a readme, but you can take a look at these benchmarks.
Here is the repo: https://github.com/Guthib-of-Dan/proposal-arraybuffer-detach
In file “cxx/v8.cxx” you can find the source code; file “cxx/compare.mjs” measures the performance;
In GitHub Actions CI I run all the tests and the one considering C++ is labelled as “C++ addon - detach method comparison (V8 API vs NAPI)
https://github.com/Guthib-of-Dan/proposal-arraybuffer-detach/actions/runs/23688823663/job/69012757341

[Guthib-of-Dan]

My idea is to propose ArrayBuffer.prototype.detach, but readme will be created as soon as I write one more proposal which is somehow coupled with this one.