Benchmarking Socket.IO Servers

Source: Dev.to

The Setup

The Contenders

ws is the default. It’s pure JS and reliable, but not fast (spoiler: it isn’t).

The test server is a slightly altered version of the backend of my recent project, Versus Type – a real‑time PvP typing game. I stripped out auth, rate‑limits, and DB calls.

For the load generator I use Artillery with the artillery-engine-socketio-v3 plugin to simulate thousands of concurrent clients connecting via WebSocket and playing the game.

Hardware

Attack Flow

1. Artillery spawns 4 virtual users per second.
2. Each user calls /api/pvp/matchmake.
3. The server runs a matchmaking algorithm and returns a room ID (max 6 players per room).
4. Users connect via WebSocket, join the room, and receive the game state (the passage).
5. Server broadcasts a countdown; players wait until it reaches 0.
6. Users emit a keystroke event at 60 WPM (≈ 1 event / 200 ms).
7. For every keystroke the server validates the input, updates state, and broadcasts the new state to everyone in the room.
8. Users send a ping event every second for latency tracking.

The passage is long enough to ensure no game ends before the benchmark finishes.
(Real server also broadcasts system messages and WPM updates each second.)

GitHub repo: (includes server, client, and result data).

The Results

Overall Winner

Node + uWS (blue line) outperformed every other configuration in all metrics except memory usage, where Bun took the lead.

0 – 800 Clients

• The Bun servers have significantly lower event‑loop lag (~0 ms) than the Node servers.
• node‑uws is the most stable.
• The ws servers (both Bun and Node) see latency p95 creep up to 15‑20 ms.
• The other two configurations stay rock‑solid at ≈ 5 ms.

800 – 1 500 Clients

• node‑ws explodes – latency spikes around 1 k clients.
• bun‑ws and bun‑native follow, but later.
• Event‑loop lag follows the same pattern.
• CPU hits 100 % for node‑ws at ~1 k clients, bun‑ws at ~1.2 k, bun‑native at ~1.3 k.
• node‑uws stays at ≈ 80 % CPU even at 1.5 k clients, rising at a similar rate to the others.
• Throughput becomes unstable for all except node‑uws.
• Memory: node‑uws shows a strange dip before climbing back; the Bun servers use less memory overall – Bun’s memory management is impressive.

Bottom line: node‑ws cannot handle the load, while node‑uws remains chill with flat latency and low event‑loop lag.

1 500 – 2 100 Clients

• node‑ws, bun‑ws, and bun‑native are effectively dead – latency through the roof.
• node‑uws still runs at a constant ≈ 80 % CPU with low latency.
• Note: node‑ws’s p95 latency appears flat for a while (lower than bun‑native) because metrics stopped being recorded; Artillery’s pushgateway shows the last recorded value until a new one arrives.

2 100 – 3 300 Clients

• node‑uws continues to hold steady – CPU stays around 80 %, latency remains low, and the server stays responsive.
• All other configurations are overwhelmed – CPU at 100 %, massive latency spikes, and frequent crashes.

Takeaways

Bottom line: If you need raw performance for a high‑traffic real‑time app, Node + uWebSockets.js is the clear winner. If memory is a primary concern and you’re comfortable with Bun, the Bun native engine is a solid secondary choice – just keep an eye on its scalability limits.

![Benchmark Graph](https://media2.dev.to/dynamic/image/width=800,height=,fit=scale-down,gravity=auto,format=auto/https%3A%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Farticles%2Fj46ux807ur388inzxs51.png)

`node-uws` is the only one still standing. It's at ~90‑100 % CPU now.

Throughput starts to become less stable, and latency slowly creeps up. It goes dead after ~3 250 clients.  
We can say it could handle a solid 3 000‑3 100 concurrent clients just fine—more than double the next best (`bun-native`).

Full Graph

CSV files are available here on GitHub.

Bun, What Happened?

It’s a surprise to see bun-native get absolutely destroyed here, because the Bun WebSocket server uses uWebSockets under the hood.

I don’t exactly know the reason why, but it might be because @socket.io/bun-engine is still very new (v0.1.0) and may have inefficiencies and abstraction layers that add overhead.