Cameleering
simoomsimoom / Compare / may-minihttp vs simoom
Two servers built for throughput
may-minihttp vs simoom
may-minihttp is a minimal HTTP/1.1 server on the may stackful coroutine library, well known from benchmark tables. In benchmark campaign 4 (2026-11-12) it was the only server ahead of simoom on the status endpoint at 256 clients. Here is where it leads, and where simoom does.
may-minihttp and simoom at a glance
Wins and losses in one table. may-minihttp 0.1.11 from its pinned Cargo.lock, on the same DigitalOcean c-4 droplet as simoom in each round of campaign 4.
| may-minihttp | simoom | |
|---|---|---|
| Model | stackful coroutines (may) | one event loop per CPU core; plain functions, no async |
| Protocols | HTTP/1.1 | HTTP/1.1, HTTP/2, HTTP/3, TLS 1.3, WebSocket, server-sent events, a client |
| Status endpoint, 64 / 256 / 1,024 clients (req/s, 99% within 1 ms) | 158,598 / 154,590 / 155,048 | 137,443 / 145,082 / 133,243 (may-minihttp 15% / 6% / 16% more) |
| JSON API, 1 KB in and out, 256 clients (req/s, 99% within 1 ms) | 131,427 | 123,040 (may-minihttp 5% more) |
| p99 at a fixed 50,000 req/s | 400 µs | 355 µs |
| CPU per request at a fixed 50,000 req/s | 28.2 µs | 23.4 µs |
| Traffic spike at 195,000 req/s offered, answers within 1 ms | 4,811/s | 6,264/s |
| p99 of real requests under 11,000 slow attackers | 1,073 µs | 568 µs |
| Memory per connection, 10,000 idle connections | 20,293 B | 575 B |
| Peak memory while serving the status endpoint (PSS) | 28,936 KB | 2,924 KB |
| Start-up to first answer | 8.03 ms | 0.90 ms default build; 1.20 ms full server |
| Program size, stripped | 515 KB (HTTP/1.1 only) | 735 KB default build (HTTP/1.1, HTTP/2, WebSocket); 1,550 KB full server |
Campaign 4, 2026-11-12: may-minihttp and simoom on the same droplet in the same rounds, median of rounds; simoom's figure is from those same runs. An HTTP/1.1-only simoom build was not part of campaign 4; its size budget is in features and size. Every measure: the benchmarks.
Every measure, head to head
Each cell: simoom against that server on the same droplet in the same round, median of rounds, then the server's value against simoom's in the same runs. Every measure and every other server: the benchmarks.
An earlier round
An earlier campaign (campaign 3, 2026-11-11) ran before a fix that keeps simoom's event loops off the CPU busiest with network-card interrupts (bug K12 in the repository), and read differently. Campaign 4 supersedes it; its figures stay in bench/results/2026-11-11-campaign3/ and are not used on this site.
When to pick may-minihttp instead
Pick may-minihttp when
- HTTP/1.1 is all you serve and you want the most requests per second: in campaign 4 it answered 6-16% more status requests than simoom, and its program is 515 KB against 735 KB for simoom's default build.
- Your network path is unreliable: in an earlier campaign (2026-11-11) it held up best on a droplet with a degraded network path. Campaign 4 did not test that case.
- You are comfortable with stackful coroutines. Whether they can be made fully sound in Rust is an open discussion; read it and decide for yourself.
Pick simoom when
- You need HTTP/2, HTTP/3, TLS, WebSocket or a client in the same program.
- CPU, latency or memory matter more than peak throughput: in campaign 4 simoom used 15% less CPU per request, held 35x less memory per idle connection and started 8.9x faster.
- You want strict, bounded parsing: every limit has a default, h2spec 146/146, HTTP Garden with 0 desyncs.
- You want blocking work handled for you: a bounded offload pool that answers
503instead of queueing forever. - You want no third-party crates at all, and
unsafeconfined to one crate.
How it was measured
Setup
- DigitalOcean
c-4droplets (4 dedicated vCPUs, Xeon Platinum 8280, Bangalore), Ubuntu 24.04. - One server droplet and two load droplets; open-loop load at fixed rates.
- may-minihttp 0.1.11 from its pinned
Cargo.lock.
Rules
- Headline: the highest steady rate whose p99 stays at or under 1 ms.
- Campaign 4, 2026-11-12: simoom ran on the same droplet in the same round as may-minihttp; every figure is the median of rounds.
- Raw HDR logs, scripts and analyses are in
bench/results/.
Common questions
What is a good may-minihttp alternative?
If you like may-minihttp for its throughput without tokio but need more than HTTP/1.1, simoom covers HTTP/1.1, HTTP/2, HTTP/3, its own TLS 1.3, WebSocket and a client with no third-party crates. On the same droplet in benchmark campaign 4 (2026-11-12), may-minihttp answered 6% more status requests per second at 256 clients and its program is smaller (515 KB against 735 KB for simoom's default build), while simoom used 15% less CPU per request, started 8.9x faster and held 35x less memory per idle connection. If you want a framework on tokio instead, look at axum or xitca-web.
Is may-minihttp faster than simoom?
On plain throughput, yes. In benchmark campaign 4 (2026-11-12), with both servers on the same droplet in the same rounds, may-minihttp answered 15%, 6% and 16% more status requests per second than simoom at 64, 256 and 1,024 clients, and 5% more on the 1 KB JSON API. simoom had the lower p99 at a fixed 50,000 req/s (355 µs against 400 µs), used less CPU per request (23.4 µs against 28.2 µs) and answered 30% more requests within 1 ms during a traffic spike. may-minihttp's program is also smaller: 515 KB against 735 KB for simoom's default build.
What is the fastest Rust HTTP server?
There is no single answer: it changes with the machine, the number of connections and the test. In benchmark campaign 4 (2026-11-12), with each server on the same droplet as simoom, may-minihttp led the status endpoint at 256 clients with 154,590 req/s, 6% more than simoom; simoom came second of 19, 24% ahead of hyper. simoom was first of 19 on CPU per request and first of 8 on HTTPS throughput, H2O led HTTP/2 and HTTP/3, and actix-web led the traffic spike. Measure on your own hardware with your own traffic.
Does may-minihttp support HTTP/2 or TLS?
may-minihttp is a minimal HTTP/1.1 server, best known from benchmarks. simoom adds HTTP/2, HTTP/3 over QUIC, TLS 1.3, WebSocket and server-sent events as cargo features, and an HTTP/1.1-only build is available when that is all you need.
Quick start
For an HTTP/1.1-only build like may-minihttp's, turn simoom's default features off.
# Cargo.toml
simoom = { version = "0.1", default-features = false, features = ["http1"] }