I Chased uWebSockets—and Found a 14-Byte Performance Cliff

hamdallah jodah — Fri, 31 Jul 2026 22:54:09 +0000

Building ramjet-ws-js: a Rust-backed WebSocket path for Node.js that wins where it matters, admits where it loses, and survived 584 million verified round-trips.

The benchmark result I learned the most from was not a win.

At exactly 64 KiB, my WebSocket server was 8.42% slower than uWebSockets.js. It did not crash. It did not corrupt the message. It simply crossed an invisible boundary and became slower.

The reason was fourteen bytes.

That small discovery ended up explaining the entire project better than any headline performance number.

What I was building

ramjet-ws-js is a JavaScript WebSocket API backed by a Rust networking core.

The normal JavaScript message path looks roughly like this:

Socket → Rust decoder → V8/JavaScript callback → Rust → Socket

That design is flexible. A handler can run any JavaScript logic it wants.

But flexibility has a cost. Every message crosses the Rust-to-JavaScript boundary, creates or transfers a JavaScript buffer, invokes a callback, then sends the response back into Rust.

For handlers whose behavior is already known, that journey is unnecessary.

So I added an opt-in native execution path:

const { App } = require('ramjet-ws')

const app = App()

app.ws('/*', {
  nativeEcho: true
})

app.listen(9001)

With nativeEcho, the data path becomes:

Socket → Rust decode and unmask → Rust echo → Socket

Open and close events can still reach JavaScript, but message frames stay inside the native reactor.

This is not a trick that makes arbitrary JavaScript 46% faster. It is a different execution model: declare simple behavior in advance, then let the native runtime execute it without visiting V8 for every message.

In one controlled comparison, the optimized JavaScript callback path reached 400,858 requests per second. The declared native path reached 587,912.

That was a 46.7% improvement inside the same application.

More than simply removing a callback

Avoiding JavaScript was only the beginning.

For eligible frames, Ramjet reuses the pooled receive buffer for the response. It unmasks the client payload in place, inserts the server response header, and submits the same buffer for writing.

When multiple frames arrive together, the reactor processes them as one fused batch. Unmasking and compaction happen in one pass, and the replies are corked into one write.

Tiny messages behave differently. For a single small read, the compact streaming encoder was faster than the fused machinery, so the path switches adaptively.

The generic JavaScript path also received several improvements:

Ordered event batching instead of one native callback per event
Coalesced wakeups between JavaScript and the reactor
Per-connection atomics instead of a global lock and lookup
Size-aware buffer ownership
Exact outbound accounting and bounded backpressure
Explicit handling for retained, mutated, and repeatedly sent Node.js buffers

The result is not one clever optimization. It is a collection of small decisions that keep unnecessary work out of the hot path.

Benchmarking without lying to myself

Performance testing becomes marketing very easily.

To avoid that, I tested Ramjet against uWebSockets.js, which is backed by uSockets and is one of the strongest WebSocket baselines available.

Both servers ran on the same AWS C7i.large:

Two logical CPUs on one physical Xeon Platinum 8488C core
Linux 7.0
Node.js 22.16.0
Server pinned to CPU 0
Client pinned to CPU 1
Compression disabled
Same 32 MiB maximum-message configuration
One server running at a time
Warm-up before every measured run
Mirrored execution order
Three measured runs, reported as medians

The benchmark client did not merely count responses. It verified the opcode, payload size, and exact echoed bytes. A fast incorrect response counted as a failure, not a result.

Where Ramjet was strongest

The most convincing result came from small pipelined traffic.

With 200 connections, pipeline depth eight, and frames written in bursts:

Ramjet: 599,829 requests/second
uWebSockets.js: 518,658 requests/second
Ramjet throughput advantage: 15.65%
Ramjet p50 latency: 14.38% lower
Ramjet p99 latency: 13.28% lower

With 50 connections and one 64-byte message in flight, the result was much closer:

Ramjet: 169,468 requests/second
uWebSockets.js: 166,462 requests/second
Ramjet advantage: 1.81%

That distinction matters. The design is especially strong when frames arrive in batches and the reactor can fuse work, reduce submissions, and reuse buffers.

The payload sweep produced a more interesting picture:

Payload	Ramjet	uWebSockets.js	Difference
1 KiB	131,248 msg/s	129,985 msg/s	Ramjet +0.97%
4 KiB	91,773 msg/s	91,183 msg/s	Ramjet +0.65%
8 KiB	72,597 msg/s	69,358 msg/s	Ramjet +4.67%
64 KiB	16,755 msg/s	18,294 msg/s	Ramjet −8.42%
128 KiB	9,057 msg/s	8,782 msg/s	Ramjet +3.14%
256 KiB	4,463 msg/s	3,765 msg/s	Ramjet +18.55%
512 KiB	1,784 msg/s	1,729 msg/s	Ramjet +3.23%
1 MiB	811 msg/s	865 msg/s	Ramjet −6.19%
2 MiB	387 msg/s	420 msg/s	Ramjet −7.83%

Ramjet is not universally faster. No honest benchmark says that.

It is particularly strong for small pipelined traffic and payloads through roughly 512 KiB. uWebSockets.js currently leads at one and two MiB, where Ramjet's full-message reassembly and copying become more expensive.

The fourteen-byte problem

A 64 KiB payload contains exactly 65,536 bytes.

But a masked WebSocket frame carrying that payload also needs a 14-byte header. The actual client frame is therefore 65,550 bytes.

Ramjet's pooled receive buffer is 65,536 bytes.

The frame misses the whole-buffer fast path by fourteen bytes.

The connection still works. Ramjet safely falls back to streaming and reassembly. But it loses the in-place buffer reuse that makes nearby payload sizes fast.

I tested a bounded "tail stitch" workaround that joined the missing bytes onto the pooled buffer. It sounded clever.

It was slower.

So I removed it.

That is an underrated part of performance engineering: a clever optimization that loses in a controlled benchmark is not clever enough to keep.

Interestingly, the performance did not continue falling after the boundary. Ramjet moved ahead again at 128 KiB and produced its largest payload advantage at 256 KiB.

The 64 KiB result was a boundary effect, not a general inability to process large messages.

Speed without stability is only a demo

After the short benchmarks, I left the same server process under mixed saturation for thirty minutes.

Every minute, 95 connections were created across four concurrent workloads:

50 connections sending 64-byte frames with pipeline depth eight
30 connections sending 1 KiB messages
10 connections sending 128 KiB messages
Five connections sending 256 KiB messages

The clients ran for 58 seconds, disconnected, and reconnected for the next cycle.

The final result:

584,779,917 exact round-trips
Approximately 833 GiB of application payload across both directions
2,850 connection sessions
120 out of 120 workload runs successful
Zero payload mismatches
Zero client failures
Zero server crashes
Zero unexpected timeouts

The original server process remained alive for the entire test.

Memory told the same story:

Initial RSS: 44.9 MiB
Final RSS: 55.8 MiB
Maximum observed RSS: 56.7 MiB
Process high-water mark: 57.9 MiB

The memory high-water mark was established during the initial allocator warm-up and did not continue climbing.

File descriptors moved from 24 at rest to 119 under load and returned to 24 after every reconnect cycle.

That repeatable 24 → 119 → 24 pattern was more meaningful to me than a single high requests-per-second number. It showed that connections and their resources were actually being retired.

Median performance during the mixed soak was:

Workload	Throughput	p50	p99
64-byte burst	297,474 msg/s	1.26 ms	2.83 ms
1 KiB	36,081 msg/s	0.78 ms	2.09 ms
128 KiB	1,011 msg/s	9.45 ms	14.67 ms
256 KiB	258 msg/s	19.10 ms	26.30 ms

These numbers are lower than the isolated benchmarks because four clients were sharing the same client CPU simultaneously. The point of the soak was stability under contention, not producing another leaderboard result.

The limits are intentional—and visible

The decoder currently accepts messages up to 32 MiB, but native echo has a four MiB per-connection outbound safety budget.

Because a large server-to-client WebSocket frame needs a 10-byte header, the largest native echo payload is:

4,194,304 − 10 = 4,194,294 bytes

I tested the boundary directly:

A 4,194,294-byte payload succeeded.
A 4,194,295-byte payload was rejected with WebSocket close code 1008.
An exact four MiB payload was also rejected.

This is not a parser bug. It is backpressure doing what it was designed to do.

Simply raising the limit would be easy, but it would allow slow clients to pin much more memory. A better future design is to allow one oversized in-flight message when the normal queue is empty, then stream it through multiple pooled buffers using vectored writes.

That would preserve bounded backpressure while supporting larger messages efficiently.

Verification beyond benchmarks

The final artifact passed:

cargo fmt --check
cargo clippy --all-targets -- -D warnings
cargo test
npm run build
npm test
git diff --check

The integration suite covers native text and binary echo, pipelined ordering, 64 KiB and 128 KiB messages, close handling, backpressure, retained buffers, mutated buffers, repeated sends, handle cleanup, and connection leaks.

The exact Linux artifact used for the final tests had this SHA-256:

8b2d01e361349d1a7401d91c39955037d31d059219c442a3fd6c7566ff114752

This still does not prove every production workload. The benchmark ran over loopback, which isolates runtime and CPU performance rather than real network conditions. Cross-machine latency, packet loss, TLS, proxies, and unpredictable application behavior deserve their own tests.

But it proves something useful: the optimized path is fast, exact, bounded, and stable under sustained pressure.

Where I stop—and where I go next

I am stopping the echo optimization here.

Not because it is perfect, but because the evidence says the next unit of work belongs somewhere else.

The more valuable next step is an opt-in native pub/sub execution path and a thread-per-core worker API. Those features bring the same "declare behavior, skip unnecessary runtime boundaries" idea into real applications.

If production workloads regularly carry multi-megabyte messages, the vectored streaming path moves higher on the list. Otherwise, rewriting the large-message architecture to win another synthetic benchmark would add complexity without earning its place.

The best performance result in this project was not 599,829 requests per second.

It was knowing which optimization to remove, which limit to keep, and when to stop.

Links:

DEV Community: hamdallah jodah