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.

Performance usually comes with tradeoffs. These can take many forms, from skipping security checks to only optimizing a small part of the program that is being benchmarked. If you let performance guide a design other aspects of a program can suffer. Or in other words it doesn't matter how fast a broken program runs.

Despite optimization not being a priority some benchmarks are so interesting that are worth sharing. The condensing patch referenced below condenses multiple network write request into a single one.

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

server and version	requests/sec (mean)
before patches	22790.46
-O2 alone	23167.02
After the condensing patch	26393.86
After patch + -O2	30257.64
nginx/1.21.6	26683.67
lighttpd/1.4.64	fails at 500 concurrency
Apache/2.4.54	fails at 500 concurrency

bonus for 100 concurrency due to other server giving errors ab -k -c 100 -n 10000 http://localhost:<port>/

server and version	requests/sec (mean)
after patch + -O2	32136.88
nginx/1.21.6	26788.39
lighttpd/1.4.64	56971.62
Apache/2.4.54	fails at 100 concurrency

Switching from -Os to -O3 has a small performance impact, but reducing write requests adds around 4k req/s (about 20% faster). Looking at the other servers defaults I have to say I'm confused, I thought nginx would be faster, it does handle concurrency better than either apache or lighttpd though. Also it seems lighttpd is really fast at static requests.

While testing consumes time and I can't say I'm a big fan of optimization, free performance with minimal tradeoffs is best performance.

Now on to figuring out why file transfers are so slow.

They say brevity is the soul of wit. This is expecially true for programming where the more you write the farther from efficiency you get.

Even knowing that I always struggle to make managable git commits. I have no problem writing small code, but whenever version control is involved the desire to fix x and y and z gets the better of me.

Sure smaller commits are easier to review, but what about the cognitive load of fighting your urge to write long commits ? It might sound like a joke but is it really ?

I don't understand languages like rust. Why invent a new languages just for memory safety when you can write good memory safe code already. Yes even in c with a bit of learning. Rust devs instead opted to take the long way around and teach everyone a new language.

My pet conspiracy theory is that new languages are written by people who like to write documentation.

"The best way to become better at something is to fail at it 10000 times" - some smart man probably.

I've been bothered by my procrastination to write even basic things like text messages for a long time. I hate to admit it but sometimes I lose hours composing even emails. Yes I'm that bad at writing.

I need help, and the most reliable help you can possibly get is yourself. Yes you heard it right I want to get better at it. And to implement what I already said is a good plan (read fist paragraph) I decided I'm going to write here. Expect lots of weird information about writing linux servers and other similar projects.

Also if anybody has any cheatsheet or 10 quick tips article to master writing fast I'm very interested because the prospect of writing lots (and failing) isn't very appealing to me.