Benchmark2

Tue, 22 Nov 2022 16:51:21 +0000

New benchmarks are here, after several optimization patches and some unexplained performance improvements, here we are.

Optimization takes a lot of time and depends on trial and error plus modern magic, old code is rarely in a good shape, frequently breaks at the lightest change, insufficient documentation also hampers optimization efforts, and that dreaded feeling of "what does this do again ?" is encountered way too often. But the biggest problem by far is motivation, it's very hard to justify spending 90% time to increase performance by 10%; despite all of this sometimes magic prevails and the stars align to improve performance. Though I have to be honest I wish I knew why moving 3 lines of code to another function increases performance by 15k req/s.

So on to the tests, spoiler alert we managed to beat Lighttpd.

for 250 concurrency ab -k -c 250 -n 10000 http://localhost:<port>/

server and version | failed requests | requests/sec (mean)
hinsightd/0.9.17 | 0 | 63035.01
nginx/1.23.2 | 0 | 26673.64
lighttpd/1.4.67 | 0 | 53693.29
Apache/2.4.54 | 414 | 37474.10
Caddy/2.6.2 | 0 | 35412.02

for 500 concurrency ab -k -c 500 -n 10000 http://localhost:<port>/

server and version | failed requests | requests/sec (mean)
hinsightd/0.9.17 | 0 | 54984.63
nginx/1.23.2 | 0 | 26172.73
lighttpd/1.4.67 | 215 | 1613.59
Apache/2.4.54 | 1221 | 34305.55
Caddy/2.6.2 | 0 | 33995.57

Notes:

Please note I am a server developer not a server administrator and might not know of all the ways to increase performance of other servers while I know how to get every last bit of performance out of my own. So please take these kind of tests with a drop of salt.

Due to rapid io uring development and possible variance, it's needs to be noted we are using linux kernel version 6.0.9.

I wish I had the time to investigate why Lighttpd starts going very slowly when overloaded.