Hi,
as there are two more HTTP server implementations:
It was time to update some numbers!
Last results can be seen here - 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 thanhunt-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
- should be possible later to work with full D too, but it's easier to go from
- linux as an only target atm.
epoll
andio_uring
async I/O api backends (can be extended withIOCP
orKqueue
, 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 forasan
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.