hyper and axum vs simoom

hyper, axum and simoom at a glance

Wins and losses in one table. The measured rows are from campaign 4: hyper 1.12.0, axum 0.8.9 and axum with rustls, each on the same DigitalOcean c-4 droplet as simoom in the same rounds, with simoom's figure from those same runs.

Campaign 4, 2026-11-12: every figure is the median of rounds, and simoom's figure comes from the same droplet and rounds as the server it is compared with, so it differs a little from row to row. Details in 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.

When to pick hyper or axum instead

For many Rust services, axum on tokio is the right answer, and that is fine.

What the code looks like

No async, no runtime to start. A route is a function that takes the request and a reply.

use simoom::{Outcome, Reply, Request, Router, Server};

let router = Router::new()
    .get("/health", |_: &mut Request<'_>, r: Reply<'_>| r.body_static(b"ok"))
    .get("/users/:id", |req: &mut Request<'_>, r: Reply<'_>| -> Outcome {
        let id = req.param_str("id").unwrap_or("").to_string();
        r.header("content-type", "application/json").body(format!("{{\"id\":\"{id}\"}}"))
    });

let server = Server::builder().listen("0.0.0.0:8080").service(router).start().expect("start");

Slow work (a database query, a call to another service) goes to the bounded offload pool with simoom::blocking, or to your own threads with Reply::defer. See routing and slow work.

How it was measured

Method and every number: benchmark method, the losses.

Try it next to your hyper service

Add the crate, serve the same route on another port, and measure both on your own machine.

cargo add simoom