:zap: fast http framework for rust

Daniel Oltmanns

Last update: Jun 7, 2022

Overview

`zap` ⚡

The mission of zap is, to deliver a basic, but fast rust web server library.

Documentation

About

This code is based on tokio's minihttp project, so a big thanks to them. (source)

The goal of this project is, to show how fast Rust can be. It isn't made for huge complex applications, just a test project for benchmark reasons.

How to use

Add the following to your Cargo.toml:

[dependencies]
zap = "0.0.4"

Speed

So zap is not only fast, it is wapping 2.96 times faster than iron, which is based on hyper. Benchmarks below:

Benchmark Code

Iron

This code had been taken from the ironframework.io webpage.

extern crate iron;

use iron::prelude::*;
use iron::status;

fn main() {
    fn hello_world(_: &mut Request) -> IronResult<Response> {
        Ok(Response::with((status::Ok, "Hello World!")))
    }

    Iron::new(hello_world).http("localhost:3000").unwrap();
}

Zap

This example can be run, by:

$ git clone https://github.com/oltdaniel/zap && cd zap
$ cargo run --example hello-world --release

extern crate zap;

use std::io::Error as ZapError;
use zap::prelude::*;

struct HelloWorld;

impl Handler for HelloWorld {
    type Request = Request;
    type Response = Response;
    type Error = ZapError;
    type Future = ZapResult;

    fn call(&self, _: Request) -> ZapResult {
        let mut resp = Response::new();

        resp.body("Hello World!");

        resp.ok()
    }
}

fn main() {
    let addr = "0.0.0.0:8080".parse().unwrap();
    let mut server = Server::new(Http, addr);
    server.threads(8);
    server.serve(|| Ok(HelloWorld));
}

Benchmark Results

The benchmark results have been computed with this command: wrk -t16 -c500 -d10s http://127.0.0.1:8080 --latency

Technical details about the server:

Intel Core I7-6700K, hyper-threaded
16GB RAM, 2400MHZ

Detailed results: in the wiki.

Iron

[...]
Requests/sec: 307581.17
Transfer/sec:     33.44MB

Zap

[...]
Requests/sec: 912832.31
Transfer/sec:     40.90MB

Credits & License

Daniel Oltmanns & others

Basically do what you'd like to.

Comments

bytes - memory allocation
As the benchmark results show:

test tests::bench_allocate_pieces ... bench: 2,501 ns/iter (+/- 80) test tests::bench_allocate_pile ... bench: 1,279 ns/iter (+/- 74)

Allocating a big pile is faster then allocating it in small pieces. The problem is, collecting the data we need to write and then push it into the buffer.
opened by 0x1daniel 3
performance - CPU heavy requests block threads

Since we don't process each request apart from another, CPU heavy requests block the threads.

Can be solved by Accepting requests with go Ok(HandlerName)
bug enhancement

opened by daniel-Q6wUOI 2
requets - Empty reply on more than 16 headers
Cause we need to give httparse a fixed size of headers, I want to get rid of it. So let's build a custom implementation of HTTP Request parsing.

It should work as the following:

Just make a new bytes::BytesMut object out of the headers

when a header is requested, search in the BytesMut and return an array of result (why an array? Headers can be defined more than one times, alternative: Keep first header value, ignore others)

This can lead to a performance improvement!?
enhancement help wanted
opened by daniel-Q6wUOI 2
Compare it to other implementations

Hi,

It would be nice if you could explain just in few sentences what implementation strategy you've chosen that makes your implementation faster.

I'm the co-author of tk-http yet another http implementation in rust. It's also different from hyper in several things, in particular of how buffering is done and makes API more low-level allowing more optimizations on application level (i.e. de/serialize right into connection buffer, etc.). Also, we don't try to parse headers into type-safe things proactively (i.e. only parse headers need for this specific handler) which also saves CPU and avoids many memory allocations.

I haven't tested performance lately, as we focus more on correctness, but we are already running our implementation in production and it works pretty nice (as part of swindon project).

By writing this I'm trying to say that if your implementation makes similar assumptions and optimizations it would be great to join our effort.
wiki

opened by tailhook 2

performance - Benchmarks show bad performance

As we can see in the benchmark results by running cargo bench:

Running target/release/deps/push_bytes-00e4ab3141864ae0

running 6 tests
test tests::bench_all_combined      ... bench:          26 ns/iter (+/- 1)
test tests::bench_convert_and_push  ... bench:           6 ns/iter (+/- 0)
test tests::bench_extend_from_slice ... bench:           8 ns/iter (+/- 0)
test tests::bench_fastwrite         ... bench:          13 ns/iter (+/- 1)
test tests::bench_push_to_buffer    ... bench:           6 ns/iter (+/- 0)
test tests::bench_string_to_push    ... bench:           6 ns/iter (+/- 0)

test result: ok. 0 passed; 0 failed; 0 ignored; 6 measured; 0 filtered out

A combination of all functions we use is a bad option. Also we should get rid of FastWrite and convert it by our own, that saves us some time as test tests::bench_fastwrite and test tests::bench_string_to_push show.

Any ideas how to get the last ns out of the IO writing part?

enhancement

opened by daniel-Q6wUOI 1

Releases(v0.0.4)

v0.0.4(Nov 13, 2017)
Following things had been changed:

We removed httparse for better perfomance, now 2.96x faster than iron

Request object variables changed, see here

Source code(tar.gz)
Source code(zip)
v0.0.3(Oct 12, 2017)
Request::body returns real body content

Clearing buffer after request

Access to raw request data

Source code(tar.gz)
Source code(zip)
v0.0.2(Oct 6, 2017)
We made some massive performance improvements.

Faster response writing

response.status(200, "OK") had been replaced with response.status(200)

Documentation has some infos

Source code(tar.gz)
Source code(zip)
v0.0.1(Oct 2, 2017)

Source code(tar.gz)
Source code(zip)