Tracking issue for WebSocket performance

[littledivy]

Let's look at a simple ping/pong benchmark.

Deno.serve(req => {
  const { socket, response } = Deno.upgradeWebSocket(req);
  socket.onmessage = (e) => {
    socket.send(e.data);
  }
  return response;
}, { port: 8000 });

# Deno 1.26.1
Msg/sec: 74114.500000

# uWebSocket.js
Msg/sec: 259207.750000

The goal should be to have as little overhead as possible and be on par with uWebSocket.js and tokio-tungstenite. We should also integrate this test using uWebSockets/benchmarks/load_test.c in our CI workflow.

After applying the below changes, I see a ~3.5x improvement in the above benchmark:

# Deno (with below changes)
Msg/sec: 258291.750000

• Optimize socket[_idleTimeoutDuration] logic. chore(ext/websocket): deprecate and remove idleTimeout #16317
• Do not create bunch of Error objects during timer cancellation. perf(ext/web): optimize timer cancellation #16316
• Make op_cancel_handle use fast calls. perf(ext/web): optimize op_cancel_handle #16318
• Use core.byteLength instead of doing full utf8 string encoding. perf(ext/websocket): optimize socket.send #16320
• Fast path for sending string and binary values. perf(ext/websocket): optimize socket.send #16320
• op_try_send_[type] fast call to try to send values in one go without creating a future. perf(ext/websocket): optimize socket.send #16320
• Optimize op_ws_next_event:
  • Make it deferred. We don't want to poll unless there is an event. perf(ext/websocket): optimize op_ws_next_event #16325
  • Since it's deferred, pushing the future onto the event loop should be a fast call. This takes up 10% of the time.
    • Do not progress deferred ops immediately. perf(core): do not eagerly progress deferred ops #16361
    • fast calls.
  • It should return value ID. perf(ext/websocket): optimize op_ws_next_event #16325
  • Fast path to get values from ID. NextEventResponse is slow. perf(ext/websocket): optimize op_ws_next_event #16325
• AsyncRefCell try_borrow_mut before borrow_mut().await. perf(ext/websocket): optimize socket.send #16320
• Optimize Event and MessageEvent:
  • event timestamp does not have to be perfect.
  • ReflectDefineProperty causes deopt. perf(ext/websocket): skip Events constructor checks #16365
  • Fast path for internal message dispatch to avoid webidl and ReflectHas checks. perf(ext/websocket): skip Events constructor checks #16365
• Optimize op_queue_microtask. perf(core): avoid creating global handles in op_queue_microtask #16359
• Do not create a new Uint8Array for serde_v8::StringOrBuffer. perf(serde_v8): serde_v8::StringOrBuffer return JS ArrayBuffer instead of Uint8Array #16360

A very sloppy implementation of the above can be found here: main...littledivy:deno:websocket_perf

[uNetworkingAB]

Always good when perf. is getting better across the industry but I find it a bit underwhelming when I've been pointing this out long before Deno was even conceived, yet received not the slightest ack. or response until someone else (in this case Bun) decided to actually listen to the input given. Anyways - I hope Deno will improve here because it will make us all waste less resources doing common things.

[uNetworkingAB]

Btw, if you like load_test.c there is a similar one for http that performs much better than wrk (and hence gives more accurate numbers) under uSockets/examples/ it's called http_load_test.c.

That benchmark could sure see some improvements, but is pretty fine as is for finding perf. regressions or differences.

[littledivy]

Reverted commits (due to bugs):

• revert 9ea0ce61981aa09851c3d1e0a2b7dbd7f7a392f5 #16501
• Revert "fix(ext/websocket): make try_send ops infallible (#16454)" #16743

cc @billywhizz

[bartlomieju]

@littledivy should we open a new issue for tracking WebSocket performance? It appears most (all?) things listed here were already addressed

[littledivy]

Yeah, I'll open a new one soon.