Pipelined requests fails if route is Async

[dalisoft]

server.js

const uWS = require('uWebSockets.js');
const uwsapp = uWS.App();

uwsapp.get('/synctest', (res) => res.end(JSON.stringify({ test: 23456 }))); // <-- This works as expected
uwsapp.get('/test', async (res) => {
  let isAborted = false;
  res.onAborted(() => {
    isAborted = true;
  });

  const { test } = await new Promise((resolve) => {
    setTimeout(() => {
      resolve({ test: 123 });
    }, 1);
  });
  if (isAborted) {
    return;
  }

  return res.end(JSON.stringify({ test }));
}); // <-- But this doesn't work

uwsapp.listen(8005, (token) => token && console.log('listens at 8005'));

and call node server.js then autocannon -c100 -p100 -d1 -m GET http://localhost:8005/test

results

❯ autocannon -c100 -p100 -d1 -m GET http://localhost:8005/test
Running 1s test @ http://localhost:8005/test
100 connections with 100 pipelining factor

┌─────────┬───────┬───────┬────────┬────────┬──────────┬──────────┬───────────┐
│ Stat    │ 2.5%  │ 50%   │ 97.5%  │ 99%    │ Avg      │ Stdev    │ Max       │
├─────────┼───────┼───────┼────────┼────────┼──────────┼──────────┼───────────┤
│ Latency │ 55 ms │ 72 ms │ 107 ms │ 107 ms │ 83.34 ms │ 19.31 ms │ 107.42 ms │
└─────────┴───────┴───────┴────────┴────────┴──────────┴──────────┴───────────┘
┌───────────┬───────┬───────┬───────┬───────┬───────┬───────┬───────┐
│ Stat      │ 1%    │ 2.5%  │ 50%   │ 97.5% │ Avg   │ Stdev │ Min   │
├───────────┼───────┼───────┼───────┼───────┼───────┼───────┼───────┤
│ Req/Sec   │ 6     │ 6     │ 6     │ 6     │ 6     │ 0     │ 6     │
├───────────┼───────┼───────┼───────┼───────┼───────┼───────┼───────┤
│ Bytes/Sec │ 426 B │ 426 B │ 426 B │ 426 B │ 426 B │ 0 B   │ 426 B │
└───────────┴───────┴───────┴───────┴───────┴───────┴───────┴───────┘

Req/Bytes counts sampled once per second.

6 requests in 1.1s, 426 B read
6 errors (0 timeouts)
~ 

Or may occur while using wrk with pipeline script. Tried here

[ghost]

This is by design. We had an issue about this before. Pipelining is not supported, it just happens to work if you respond immediately

[pixelzor]

Sorry to jump on this old thread. But couldn't find a clearer answer anywhere else.
I'm a bit confused @uNetworkingAB if you could clarify something for me.
Is this no longer an issue? Or am I lucking out or I don't understand what pipeling is (persistent http connections in parallel?).

I'll explain:

I'm just about ready to update a system with thousands of clients using websockets.
I, hoping to centralize some things, implemented several basic async get operations.
All of them at least asyncly validate: the httponly cookie, and check Redis.
The system is highly interactive - many ws messages being exchanged frequently.
Usually users on this system, may also have multiple tabs opened, performing different operations concurrently.
As per your advice, elsewhere, for performance, when the payload exceeds a certain size, I send them an id through ws, for them to fetch via get.
This approach has worked well in controlled tests, even when I purposely caused crashes, redis disconnects, unavailable information, causing the http request to idle with promises for a few second, with retries/timeouts and the eventual replies.

I just know I will have many users performing multiple requests simultaneously.

Should I not use uWS for this http requests? Thought they were pretty basic.
Sorry, got confused for this thread, as I haven't bumped into this issue, but also didn't perform "batches of tests" like this user apparently did.

Thanks in advance.

[uNetworkingAB]

Or am I lucking out or I don't understand what pipeling is (persistent http connections in parallel?).

Almost no tool will use Http1.1 pipelining because it is a really crappy feature and many servers don't even support it (uWS doesn't). No web browser uses it and no proxy uses it.

It's not the same as keep-alive (persistent https connections)