ehttpd 0.14.0

A HTTP server nano-framework, which can be used to create custom small-scale HTTP server applications
Documentation 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74

[![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 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 as the developer cannot accidentally stall the entire runtime
with a single blocking call. Since threads are managed and preempted by the OS-scheduler, they offer much stronger
concurrency guarantees, and are usually more resilient against optimization issues or bugs.


### 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`, `v0.14.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   846.35us  157.90us   8.83ms   95.44%
    Req/Sec     1.19k    29.88     1.39k    72.71%
  764062 requests in 10.10s, 37.89MB read
Requests/sec:  75632.95
Transfer/sec:      3.75MB

$ wrk -t 64 -c 64 http://localhost:9999/testolope-nokeepalive
Running 10s test @ http://localhost:9999/testolope-nokeepalive
  64 threads and 64 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency     1.67ms    2.94ms  65.36ms   99.23%
    Req/Sec   298.08     58.26   360.00     88.93%
  117764 requests in 10.06s, 7.97MB read
  Socket errors: connect 64, read 0, write 0, timeout 0
Requests/sec:  11700.35
Transfer/sec:    811.25KB
```

#### Linux Machine (`Intel(R) Core(TM) i5-10400F CPU @ 2.90GHz`, `v0.14.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   193.40us  164.70us   6.74ms   88.35%
    Req/Sec     5.81k     1.36k    9.99k    73.34%
  3738117 requests in 10.10s, 185.38MB read
Requests/sec: 370077.87
Transfer/sec:     18.35MB

$ wrk -t 64 -c 64 http://localhost:9999/testolope-nokeepalive
Running 10s test @ http://localhost:9999/testolope-nokeepalive
  64 threads and 64 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency   639.38us  217.27us   5.82ms   75.14%
    Req/Sec     1.42k    75.38     2.17k    85.24%
  908872 requests in 10.10s, 61.54MB read
Requests/sec:  89987.65
Transfer/sec:      6.09MB
```