Hi,
as there are two more HTTP server implementations:
*
[Serverino](https://forum.dlang.org/thread/bqsatbwjtoobpbzxd...@forum.dlang.org)
*
[Archttp](https://forum.dlang.org/thread/jckjrgnmgsulewnre...@forum.dlang.org)
It was time to update some numbers!
Last results can be seen
[here](https://github.com/tchaloupka/httpbench#multi-core-results) - it's a lot of numbers..
Some notes:
* I've updated all frameworks and compilers to latest versions
* tests has been run on the same host but separated using VMs
(for workload generator and servers) with pinned CPUs (so they
don't interfere each other)
* as I have "only" 16 available threads to be used and in 12 vs 4
CPUs scenario wrk saturated all 12 CPUs, I had to switch it to
14/2 CPUs to give wrk some space
* virtio bridged network between VMs
* `Archttp` have some problem with only 2 CPUs so it's included
only in the first test (it was ok with 4 CPUs and was cca 2x
faster than `hunt-web`)
* `Serverino` is set to use same number of processes as are CPUs
(leaving it to default was slower so I kept it set like that)
One may notice some strange `adio-http` it the results. Well,
it's a WIP framework (`adio` as an "async dlang I/O"), that is
not public (yet). It has some design goals (due to it's targeted
usage), that some can prefer and some won't like at all:
* `betterC` - so no GC, no delegates, no classes (D ones), no
exceptions, etc.
* should be possible later to work with full D too, but it's
easier to go from `betterC` to full D than other way around and
is not in the focus now
* linux as an only target atm.
* `epoll` and `io_uring` async I/O api backends (can be extended
with `IOCP` or `Kqueue`, but linux is main target now)
* performance, simplicity, safety in this order (and yes with
`betterC` there are many pointers, function callbacks, manual
memory management, etc. - thanks for `asan` ldc team ;-))
* middleware support - one can setup router with ie request
logger, gzip, auth middlewares easily (REST API middleware would
be one of them)
* can be used with just callbacks or combined with fibers (http
server itself is fibers only as it would be a callback hell
otherwise)
* each async operation can be set with timeout to simplify usage
It doesn't use any "hacks" in the benchmark. Just a real HTTP
parser, simple path router, real headers writing, real `Date`
header, etc. But has tuned parameters (no timeouts set - which
others doesn't use too).
It'll be released when API settles a bit and real usage with
sockets, websockets, http clients, REST API, etc. would be
possible.
