https://github.com/kizzycode/ehttpd-rust

A thread-based HTTP server library, which can be used to create custom HTTP server applications
https://github.com/kizzycode/ehttpd-rust

Last synced: 6 months ago
JSON representation

A thread-based HTTP server library, which can be used to create custom HTTP server applications

• Host: GitHub
• URL: https://github.com/kizzycode/ehttpd-rust
• Owner: KizzyCode
• Created: 2023-01-28T22:45:38.000Z (almost 3 years ago)
• Default Branch: master
• Last Pushed: 2024-10-06T15:16:45.000Z (about 1 year ago)
• Last Synced: 2025-06-29T14:41:30.872Z (6 months ago)
• Language: Rust
• Size: 146 KB
• Stars: 2
• Watchers: 1
• Forks: 0
• Open Issues: 0
• Metadata Files:
  • Readme: README.md
  • License: LICENSE BSD 2-CLAUSE.md

Awesome Lists containing this project

README

          
[![License BSD-2-Clause](https://img.shields.io/badge/License-BSD--2--Clause-blue.svg)](https://opensource.org/licenses/BSD-2-Clause)

[![License MIT](https://img.shields.io/badge/License-MIT-blue.svg)](https://opensource.org/licenses/MIT)

[![AppVeyor CI](https://ci.appveyor.com/api/projects/status/github/KizzyCode/ehttpd-rust?svg=true)](https://ci.appveyor.com/project/KizzyCode/ehttpd-rust)

[![docs.rs](https://docs.rs/ehttpd/badge.svg)](https://docs.rs/ehttpd)

[![crates.io](https://img.shields.io/crates/v/ehttpd.svg)](https://crates.io/crates/ehttpd)

[![Download numbers](https://img.shields.io/crates/d/ehttpd.svg)](https://crates.io/crates/ehttpd)

[![dependency status](https://deps.rs/crate/ehttpd/latest/status.svg)](https://deps.rs/crate/ehttpd)

# `ehttpd`

Welcome to `ehttpd` 🎉

`ehttpd` is a HTTP server library, which can be used to create custom HTTP server applications. It also offers an

optional built-in threadpool-based server for simple applications (feature: `server`, disabled by default).

## Threadpool-based server

The rationale behind the thread-based approach is that it is much easier to implement than `async/await`, subsequently

requires less code, and is – in theory – less error prone.

Furthermore, it also simplifies application development since the developer cannot accidentally stall the entire runtime

with a single blocking call; being managed by the OS-scheduler, threads offer much stronger concurrency isolation

guarantees (which can even be `nice`d or tweaked in most environments if desired).

Note that, starting with version `0.9`, the built-in server is an optional feature and needs to be enabled using the

`server` feature.

### Performance

While the thread-based approach is not the most efficient out there, it's not that bad either. Some `wrk` benchmarks:

#### MacBook Pro (`M1 Pro`, `helloworld`, `v0.7.1`)

```ignore

$ wrk -t 64 -c 64 http://localhost:9999/testolope

Running 10s test @ http://localhost:9999/testolope

  64 threads and 64 connections

  Thread Stats   Avg      Stdev     Max   +/- Stdev

    Latency     1.00ms  520.00us  27.29ms   95.96%

    Req/Sec     1.02k   262.37     6.00k    94.81%

  654074 requests in 10.10s, 32.44MB read

Requests/sec:  64756.19

Transfer/sec:      3.21MB

```

#### Old Linux Machine (`Intel(R) Core(TM) i5-2500K CPU @ 3.30GHz`, `helloworld-nokeepalive`, `v0.7.0`)

```ignore

$ wrk -t 64 -c 64 http://localhost:9999/testolope

Running 10s test @ http://localhost:9999/testolope

  64 threads and 64 connections

  Thread Stats   Avg      Stdev     Max   +/- Stdev

    Latency     2.22ms    1.00ms  60.93ms   95.30%

    Req/Sec   435.19     56.94     1.00k    85.05%

  278046 requests in 10.10s, 18.83MB read

Requests/sec:  27528.42

Transfer/sec:      1.86MB

```