Node.js vs Deno vs Bun: Serving images performance comparison

Mayank C
Tech Tonic

--

I’ve done a good number of performance comparisons in the past 2 years. All of those comparisons were good & valid at that time. However, things are changing fast these days. New technologies are coming in (like Bun), and continual better performance is coming out (recent improvements in Deno and Node.js). Going with the fast changing world, the performance comparisons also need redoing to stay relevant. Any comparisons done a year back may be totally outdated now.

In other articles, I’ve compared Node.js, Deno, and Bun for:

In this article, I’m going to compare Node.js, Deno, and Bun when serving images (aka file server). This is relooking at the performance with the recent releases in all the technologies. Let’s see if anything changes this time.

Test Setup

All the tests are executed on MacBook M1 with 16G RAM. The HTTP tester is the well known benchmarking tool called Bombardier. Bombardier is a HTTP(S) benchmarking tool. It is written in Go programming language and uses excellent fasthttp instead of Go’s default net/http library, because of its lightning fast performance. The tester runs the tests with the following levels of concurrency:

  • 10 concurrent connections
  • 50 concurrent connections
  • 100 concurrent connections
  • 300 concurrent connections

The software versions are:

  • Node.js v19.5.0
  • Deno v1.30.0
  • Bun v0.5.1

A total of 1M (1 million file serves) requests are executed in each test.

The following locally downloaded image (12K size) has been used for serving:

https://commons.wikimedia.org/wiki/File:JavaScript-logo.png

Code

Only native HTTP file servers are used in this comparison. No third-party packages or libraries are used.

Node.js

import { createReadStream } from "node:fs";
import http from "node:http";
const basePath = "./data";

http.createServer((req, resp) => {
resp.setHeader("content-type", "image/png");
resp.writeHead(200);
const fp = basePath + req.url;
const rs = createReadStream(fp);
rs.on("open", () => {
rs.pipe(resp);
});
rs.on("error", () => {
resp.writeHead(404, "Not Found");
resp.end();
});
}).listen(3000);

Deno

const basePath = "./data";

Deno.serve(async (request: Request) => {
const fp = basePath + new URL(request.url).pathname;
try {
const file = await Deno.open(fp);
return new Response(file.readable, {
headers: {
"content-type": "image/png",
},
});
} catch (e) {
if (e instanceof Deno.errors.NotFound) {
return new Response(null, { status: 404 });
}
return new Response(null, { status: 500 });
}
}, { port: 3000 });

Bun

const basePath = "./data";
Bun.serve({
port: 3000,
fetch(request) {
const fp = basePath + new URL(request.url).pathname;
try {
return new Response(Bun.file(fp));
} catch (e) {
return new Response(null, { status: 404 });
}
},
});

Bun sets the content-type and content-length headers internally.

Measurements

It’s not only about how fast a system is. A system/runtime can be very fast, but may stall the system by using too much CPU, memory, disk, etc. Some official benchmarks only focus on RPS. The more RPS, the better. Given unlimited resources, this is probably fine. However, for all practical purposes, only RPS doesn’t represent the complete picture. We need to measure latencies, and system usage too. Also, we need to see the response time distribution across different quantiles.

Here is the complete list of measurements:

  • 1st quartile (or 25th percentile) latency
  • Mean latency
  • Median latency
  • 3rd quartile (or 75th percentile) latency
  • 90th percentile latency
  • Maximum latency
  • Avg. CPU usage
  • Avg. Memory usage

Results

The following are the charts to show the results. There is one bar chart for each measurement metric. All concurrency levels are covered for each metric in the same chart.

All latencies are in microseconds

Analysis

Just like the first two cases, hello world and JSON processing, Node.js continues to be the slowest of all.

This time, Deno beats Bun by serving images faster. Deno can serve 1M image in 20 seconds, while Bun needs 24 seconds.

However, Deno’s performance comes at a high price. Deno’s CPU and memory usage is higher than Bun’s. For 300 concurrent connections, Deno uses 277% CPU, while Bun uses 94%. For the same concurrency, Deno uses 86M memory, while Bun uses 29M.

--

--