Benchmarks

Each result has its date and machine. It also lists cells where Wisp is not ahead. The native TechEmpower tables are on the home page and in bench/tfb/RESULTS.md.

This site shows the numbers of the newest release only. In the Wisp repo, bench/suites.tsv names each suite and its summary file. That file names the release and the commit it measured. When a new release is out, each suite not measured at it shows "Not measured at X yet." in place of its numbers, until it is measured again. The stamps step of cargo run -q -p wisp-gate checks the stamps and the pages.

git clone https://code.wispweb.dev/wispdev/wisp
cd wisp
cargo run -r -p bench-run -- --paths fortunes

You need Rust. bench/README.md lists every option and the frameworks compared. It also says how the harness checks each path for identical output. Compare frameworks only from the same machine.

The harnesses (bench-run, rank, native-rank, edge, rust-fastest) check each server's body against fixed answers before they time it. None ranks a cell with a failed request (a non-200 or a socket error). None ranks a run without a steal reading or with steal over the bar. An error page served fast never ranks. Throughput is the median of the runs (the mean of the middle two for an even count), with min..max beside it. The kept run of a redone one is the last, never the best.

Native, Linux

Source: bench/tfb/RESULTS.md (generated from results.json). The tables use the TechEmpower plaintext and JSON tests. Our script follows the method of the TechEmpower wrk scripts. The machine is a WSL2 VM with 12 vCPUs and 15.5 GB on a desktop PC (AMD Ryzen 7 7800X3D). The server runs on CPUs 4 and 6 and wrk on CPUs 1, 2, 8 and 10. They share the L3 cache and the memory bus of the host. Plaintext (pipeline depth 16) at 256, 1,024, 4,096 and 16,384 connections, JSON at 16, 32, 64, 128, 256 and 512. 5 runs of 15 s each in one session, the median of the valid runs. A cell gets a rank only from 5 valid runs. A cell with a client CPU at 95% or more is a lower bound and gets no rank. The valid runs are in bench/tfb/results.json. The raw wrk output stays on the machine that ran it. The release is v1.0.0-pre.3 (tag 0d2d15a03). The run used tag bench-pre3-h2 (95c716ac5), which has the product code of that release. This is not an official TechEmpower result. Overlaps of the min-max ranges are ties.

The kernel is 6.8.12-bench68, built from the Ubuntu source linux-source-6.8.0 with one patch: io_uring/kbuf.c line 552, an inverted check that made IORING_REGISTER_PBUF_RING fail. On this kernel Wisp registers buffer rings. On a kernel that refuses them Wisp lends buffers by PROVIDE_BUFFERS. That mode is not measured here, and the stock Ubuntu binary kernel is not checked. Wisp v1.0.0-pre.3 can hang on the stock WSL2 kernel 6.18, so this run does not use that kernel.

wrk has 4 CPUs because 2 limit it. In separate checks (Wisp 881724bda, after v1.0.0-pre.3) at JSON 64, 256 and 512 connections with wrk on 2 CPUs, the wrk CPUs were at 99 to 100%. Wisp reached medians of 289,559 to 292,367 with its server CPUs at 70 to 83%. Actix Web with 2 workers reached medians of 308,149 to 311,746. So at 2 wrk CPUs Actix Web is ahead of Wisp, and wrk limits both. The table below shows 4 wrk CPUs, where wrk limits neither. The number of wrk threads changes the rate of Actix Web: at 256 connections it reached 253,873 with 4 wrk CPUs in a separate run, 281,262 with 3 and 311,746 with 2. The cause is not proven.

Actix Web sets its workers to the CPUs it can use. This is a change to the TechEmpower source, because actix-server 2.2.0 uses num_cpus::get_physical(), which ignores taskset.

Wisp against Actix Web, requests a second, median (min-max), no failed request in either:

Wisp's range is above Actix Web's in all ten cells.

Plaintext, pipelined, requests per second (median of the valid runs), by connections:

Rows whose min-max ranges overlap are ties. .

JSON, requests per second (median of the valid runs), by connections:

Rows whose min-max ranges overlap are ties: 32: Express with Nuxt. 128: Express with Nuxt. 256: Express with Nuxt. 512: Express with Nuxt.

What these numbers come from:

• Driver fast path. The epoll and io_uring drivers receive, answer and send in their own turn without waking the connection's task, and for routes the build found never wait, http::on_driver answers without polling the future at all.
• One pass over the request. The request line, headers and a JSON body are read in as few passes as possible, borrowed from the receive buffer instead of copied.
• Pooled buffers. A connection holds buffers only while it has a request. Idle ones go back to a pool per thread.
• No cost for what is off. HTTP/2 (feature h2) is noticed only where HTTP/1 already refused the bytes, so HTTP/1 pays nothing. Features a route does not use add no instructions, checked by the A/B described in What Is Checked below.

Twenty Servers, Closed Loop, Linux

Source: bench/README.md ("Results on Linux") in the Wisp repo. The command is cargo run -r -p bench-run -- --rounds 6 on an Intel Xeon E3-1231 v3 (4 cores, 32 GB), kernel 7.0.0-38-generic. The run data records no commit of the tree. Each server uses 2 cores and the load generator the 2 others. 64 connections, closed loop, req/s the median of 6 rounds, steal 0.0% in every measurement, no failed request. CPU is server microseconds per request.

Wisp is first on /fortunes: 269,747, range 265,423-270,248. The next is may-minihttp with 237,925, range 229,668-240,700. Wisp is first on /page: 230,145, range 227,741-231,105. The next is may-minihttp with 198,464, range 191,616-202,414. Wisp has the lowest CPU per request on every path. On /plaintext and /json Wisp is second: 289,884 against may-minihttp 296,388, and 289,916 against 296,149. The ranges overlap (Wisp /plaintext 288,647-290,392, may-minihttp 277,200-297,577), so those two paths are ties. Peak memory is 5.7 MB, first of 20 (next hyper, 7.8 MB). Where Wisp does not win: the two ties above and deploy size (2.2 MB, 4th of 9, best Bun at 6 KB). The machine gate after the run failed on load1 3.91 (limit 0.5). The run does not meet the quiet-pipeline rule for a clean end.

Twelve Frameworks, Native, Linux

Not measured at 1.0.0-pre.3 yet.

Leptos, Dioxus and Actix Web: Instructions per Request

Release 1.0.0-pre.3, Wisp 2362ec0d, 2026-10-26. Instructions per request on the server thread (callgrind, one CPU, 100 warm-up and 1,000 measured requests), median of 3 reps (min-max), release builds. Source: bench/rust-fastest/results/ir.txt and ir-provenance.txt in the Wisp repo. Wisp is not measured at 1.0.0-pre.3: the spread of its 3 reps was above 1%.

Build Time and Dev Reload, Linux Bench Box

Source: bench/build/results/report.md and summary.json in the Wisp repo (node bench/build/measure.mjs run <contender> --runs 3), release 1.0.0-pre.3, Wisp 0d2d15a0 (the run used 1e85167d: the tag plus bench-only commits), 2026-10-27. The bench/tfb apps ran on the 4-core bench box (SMT off, kernel 6.8.0-146), all in one run. Each build ran under the bench lock after the machine drained, 3 runs per cell, the median. A run with steal over 10% would run again (none did: steal was 0% in every run). Cold is a clean build with dependencies already downloaded. Warm is the same command again. Dev reload is a file saved in the running dev server until GET serves the new text. Rank in brackets.

• Where Wisp does not win: a cold build (43.9 s, against SvelteKit 3.7 s, Nuxt 5.1 s and Axum 28.6 s) and a release build after an edit (14.9 s for logic, 15.0 s for a template, against SvelteKit 3.7 s and Axum 13.5 s), because a release build compiles Rust with fat LTO. In the dev server, a template edit shows in 48 ms against SvelteKit's 14 ms. - means the framework has no such step (no build, or no dev server in its docs).
• Dev, logic edit: a string literal edit swaps in without a compile (1 ms). A number or bool literal edit also swaps in. Any other Rust edit recompiles.

Node, Bun and Deno, Linux VPS, Ranked Run

Not measured at 1.0.0-pre.3 yet.

workerd, Linux VPS, Ranked Run

Not measured at 1.0.0-pre.3 yet.

Edge and JavaScript Hosts: Instructions per Request

Release 1.0.0-pre.3, Wisp 2362ec0d, 2026-10-26. What each server's process does per request, counted by perf stat instead of timed: user instructions of the server's process over oha -n 40000 -c 64, divided by the requests. Same 6 vCPU VPS, servers on cores 0-1, oha on 2-3. Each of three runs gives the median of 3 reps, and the table gives the median of the runs. A cell with - is not valid (fewer than 3 runs, or a spread (max - min) / median of 1% or more). Wisp raw sockets and workerd have no valid cell and are left out. k = thousand, M = million instructions. Lower is better. Source: bench/edge/README.md ("Latest pass") in the Wisp repo.

The Bun rows are left out: their warm-up was 3000 requests, too short for Bun's JIT (counts spread 14% to 19%). ir.mjs now warms Bun with 50000 requests and counts 200000 (spread under 0.5%). The cold start counts moved 2% to 15% between runs, so they are not published. The Cloudflare wasm of this bench app (bench/rank/out/wisp-cf/app.wasm) is 463,900 bytes, 177,024 with gzip -9.

What Is Checked

Tokens

Writing cost is measured by a program in the repository: cargo run -p wisp-tokens --release. See Tokens.

View This Page's Source