ewe@5 benchmarks

This page evaluates the performance of ewe@5 against seven other BEAM-based web servers. Benchmarks were conducted on August 17, 2026, across fifteen endpoints using both HTTP/1.1 and h2c (cleartext HTTP/2).

ewe@5 outperformed competitors in 11 of the 15 tested scenarios on HTTP/1. It demonstrated a 32% to 49% throughput improvement over ewe@4 across all shared test cases and a 23% to 83% advantage over mist. On HTTP/2, ewe@5 delivered roughly twice the throughput of bandit but trailed roadrunner on request heavy scenarios. The file_big endpoint on h2c represents its weakest comparative performance. See Known Bottlenecks and Limitations section.

All reported figures represent the median of five consecutive runs.

Content

• How to read these numbers
• How it was run
• Throughput: HTTP/1.1
• Throughput: HTTP/2
• Against ewe@4
• Against mist
• Against elli and roadrunner
• Against bandit on HTTP/2
• Latency
• Known bottlenecks and limitations

How to read these numbers

No network overhead. The benchmark was run entirely on localhost. The load generator and server were pinned to six dedicated CPU cores each. Real world network stack and TCP overheads are not represented in these numbers.

Numbers above 200,000 req/s are approximate. At rates exceeding 200,000 req/s, h2load’s own CPU consumption impacts the results as it competes with the server for system resources. Adjusting h2load’s thread count on the hello case produced a 14% spread ranging from 228,000 to 261,000 req/s without any changes to the server configuration. Small performance gaps in this high range should therefore be treated as approximate. Comparisons below 200,000 req/s provide more stable and reliable data.

Cases that has no native API for the implementation are skipped. Some test cases were omitted for servers lacking native API support. bandit, chatterbox, elli and httpd have no SSE API and elli and httpd cannot read a request body incrementally so the cases are skipped for them.

Every server runs on default settings. All servers were tested using default configurations. The single exception is TCP_NODELAY. elli and httpd do not enable it themselves so during the benchmark we turn it on for them since every other server already has it on by default.

Not every row survived. 95 of 740 throughput rows and 83 of 282 latency rows are missing from these tables because the server stalled, answered incorrectly or was driven past its capacity. In each case the number not really described the server’s speed.

How it was run

load        h2load, 4 threads
            h1         50 connections x 1 stream
            h2         50 connections x 10 streams
duration    10s measured, 3s warmup, 5 repeats
latency     wrk2 http/1, 50 connections, 4 threads, fixed rate ladders
cpu         server pinned to cores 0-5, load generator to cores 6-11

Throughput: HTTP/1.1

Requests per second, higher is better. Best in each row is bold.

ewe@5 achieved the highest throughput in 11 out of 15 scenarios. Three of the cases where it trailed involved small payload request handling where elli maintained an advantage. The fourth was file_big where five of the servers performed within 2% of each other, as the 5 MiB payload transfer time became the primary bottleneck.

The streaming benchmarks sent multiple frames per request:

Throughput: HTTP/2

Roadrunner led in most h2c scenarios. Known bottlenecks and limitations covers where are the flaws of ewe@5 implementation.

Against ewe@4

Shared endpoints over HTTP/1.1:

ewe@5 achieved a 32% to 49% throughput increase across all shared test cases. The remaining nine cases are omitted because ewe@4 did not successfully process multiple requests per connection.

ewe@4 shows latency degradation under sustained loads. When held at 150,000 req/s on hello_headers, its p99 latency rose to 872.96 ms while ewe@5 maintained 3.67 ms. Similarly on echo_chunked_10kb at 100,000 req/s ewe@4 recorded 511.49 ms compared to ewe@5’s 4.01 ms.

Against mist

ewe@5 showed a 23% to 39% throughput improvement on standard request cases and a 71% to 83% advantage on static file serving.

Under load ewe@5 also demonstrated lower latency percentiles. At 150,000 req/s on hello_headers, mist’s p99 latency was 9.94 ms compared to ewe@5’s 3.67 ms. At 100,000 req/s on echo_chunked_10kb mist recorded 7.12 ms against ewe@5’s 4.01 ms.

Against elli and roadrunner

These two engines represent the primary benchmarks for HTTP/1.1 performance.

elli is a mature production-proven Erlang server. ewe@5 maintained competitive performance alongside it:

There is no SSE API and no incremental body read for elli.

roadrunner competes across the whole tests:

ewe@5 led in 14 of 15 on HTTP/1.1, a few percent ahead on the plain request cases, far ahead on files and streaming.

Against bandit on HTTP/2

ewe@5 led in 11 of the 12 shared test cases showing a 65% to 110% improvement on request and file tasks and a 14% improvement on smaller stream runs. The exception is file_big which is affected by the HTTP/2 window limitation detailed in the Known Bottlenecks and Limitations section.

wrk2 has no HTTP/2 support so there are no latency numbers for this table.

Latency

wrk2 targets a fixed request rate meaning its latency percentiles account for queuing delays before transmission. If the load generator fails to maintain the target rate the server has exceeded its capacity and the resulting percentiles may no longer accurately reflect performance.

A — means the server couldn’t hold that rate.

ewe@5 achieved the lowest latency in four of the eight scenarios and remained within 0.28 ms of the top-performing server in the remaining four.

Known Bottlenecks and Limitations

HTTP/2 Request Handling: Roadrunner maintains a 22% to 36% performance lead over h2c on hello, echo cases and stream. While ewe@5 significantly outperforms bandit in these tests, roadrunner’s HTTP/2 implementation is simply faster.

Large Files over HTTP/2: ewe@5 achieves only 497 req/s compared to roadrunner’s 1,005 req/s and bandit’s 750 req/s. The bottleneck stems from the connection flow-control window. ewe@5 defaults to a static window size of 65,535 bytes without dynamic window scaling. Consequently delivering a 5 MiB response requires approximately eighty WINDOW_UPDATE round trips which must be coordinated across ten concurrent streams.

Small Payloads on HTTP/1.1: ewe@5 falls behind elli by up to 14% on specific cases like echo_1kb_headers.

SSE over HTTP/2. ewe@5 trails roadrunner by 29% to 31% on sse and sse_small over h2c.

Reproducing

To run these benchmarks locally:

cd benchmark
REPEATS=5 ./throughput.sh
./latency.sh