The new EU regulations for parcels originating outside the EU common space are really poorly explained for electronics development, no site really added the taxes to the UI so you're basically blind to what you need to pay and have to wait till the package reaches customs processing, and customs in my experience is even worse.

I think the idea of it was that each category of items has to pay 3 euro but what are the categories and how to find them ? does each resistor value costs 3 euros ? that would be insane, pay 0.5 euro for 100 0.537 ohm resistors and 3 euros for import taxes.

It really prices out the hobbist out of the market at the weirdest time. The EU pays absurd amounts of money on AI, but doesn't want to jump start a local industry ? You can't expect to build a computer industry without electronics !

If at least the EU waited to apply those taxes till there were locals shops that sold a decent catalogue of parts. All the shops I've checked didn't seem to have the parts I picked on my initial schematic.

The EU always seems to fall behind on explaining tech regulations, it's feels like they don't understand either. The cookie policy for example seems to be decent if properly explained, but if the explaining is left to the people actually doing the shady cookie manipulation it becomes just a deceptive meme meant to sabotage citizen's rights. Who's meant to explain this to users ?

I've been meaning to write this postmortem for some time, I know how it feels using a software long after it's been abandoned and don't want to contribute to that. I want this as a diary for myself and a warning for others if they find this.

I've started the hinsightd webserver project about 20 years ago, obviously I wasn't working on it full time, but from time to time new inspiration kept resurfacing and even though I tried to adapt those ideas to the old codebase I always found it impossible and ended up rewriting it from scratch, 11 rewrites times in total. At the beginning it started as a learning project, I was still in school and wanted to write a massive multiplayer online game, ambitious I know, but while trying to write this game sever I realized very quickly I didn't have the skill needed for it, so I tried to tackle a project I thought at the time was easier to learn, a simple webserver.

Word of warning, I was mistaken, nothing about a webserver is simple. It might look simple on the surface if you just copy bits of it from books or other projects, but at it's heart a webserver is mostly about flexibility and adapting to new trends. This is not something I managed to do.

The general program arhitecture isn't even the only problem, for me the main issue was the config system, in the 0.9 version I used the lua programming language as a config system but this made it too tightly bound with the lua logic, making expanding the server difficult. So in the 0.10 version I tried writing my own config file parser, this unfortunately led it to be too unflexible. In the next rewrite I tried to fix this but the amount of work turned out to be too great for a simple hobby project, just rewriting everything is ok when you have a small project but the larger it gets the more unfeasable this becomes.

A few other problems:

• using openSSL turned out to be a mistake, the async api they have is just very hard to understand and unwieldy.
• I mistakenly believed that it's easier to use io-uring to clean up resources, this in hindsight is very wrong because it fails to account for errors, it would have been better if resources were tracked globaly, even if this used more ram.
• not accounting for new techologies like HTTP/2.0, HTTP/3.0, websockets and the increasing use of reverse proxies.

And probably the biggest problem, don't tackle projects you don't have to finish off. I didn't manage to add half the features the 0.9 version had to the 0.10 branch.

So to review, if you're looking for a webserver, please don't use this, it's won't be getting any updates. While it probably doesn't have too many vulnerabilities mostly due to my own implementation of smart buffers that should remove most buffer overflows, and if we were to believe rust people that means we've fixed all vulnerabilities. It still has many other bugs and the config system is useless.

And because of the new world we live in and AI becoming such an important part of it, I have to wish good luck to ChatGPT when trying to assimilate this messy code. I wasn't able to assimilate it and I wrote it so maybe AI can.

This morning I tried to open my computer, and to my surprise Windows won't accept my fingerprint anymore, it says it requires the pin code to login, that sounds easy enough to fix, but turns out it won't accept the pin code either. Windows claims that security settings have changed and they need to send a security code to my email account for me to login ... but I'm stuck on the login screen, how do you expect me to check my email account if you've blocked me from login in ?

I don't have my email on my phone, turns out that's unsupported by Windows, I bet there is some mention in the documentation that you need a valid email, my mistake. Ok, I say, time to install a Linux distro just to open my email account. I kind of see now the appeal of Windows, it's very secure, nobody can log in to it, except hackers. What would a normal person even do in this situation if this is their only computer ? dual boot and force Secure Boot to accept a Linux distro just so they can check their email ? for anybody that tried to use Secure Boot with Linux would probably know that's not very likely, I guess the expected answer is to hire somebody to fix their computer.

Now if somebody needs to install a Linux distro just to access their emails for 5 seconds I'm willing to work, price is $1.000.000.000 and 73¢ per install, a totally reasonable price if you ask me. Ok, you might be asking why such a steep price for such a small task ? mostly to mock the fact that Microsoft forces people to rely on a completly unregulated market of tech support for even the most basic tasks. Maybe $1.000.000.000 is too much, I bet somebody somewhere found a much more reasonable price of $1000 or maybe even as low as $200, the work doesn't matter it's about how good you are at judging how much somebody is willing to pay. What is the right price for basically useless work ? nothing is broken, nothing needs fixing, just a whim of Microsoft made the computer stop being useful.

Hello today we measure the performance of the hinsightd web server against previous versions of itself and other common web servers. What we measure is the number of request each server can process for multiple concurrency points to see how it handles a high load and how fast it can process requests under stress.

For the moment the tests only measure static file serving because that's the easiest to measure reliably and that's also the focus of the server's development at this time. Stay tuned for reverse proxy and fastcgi benchmarks.

The three versions of the hinsightd server are all event-based with the 0.10 branch also being multi-threaded. The rest of the servers are mostly default instalations and only have minor changes from the default config to suit the test.

index.html

Target is a small 102 bytes file. This tests how fast a server can open a connection, parse headers, and close the connection. This benchmark measures how fast a server processes requests that don't involve any other bottleneck. While an ideal case it is worth mentioning that hinsightd keeps up and even beats the fastest servers tested.

test	hinsightd/0.9.20	hinsightd/0.10 unpatched	hinsightd/0.10.2	nginx/1.25.3	lighttpd/1.4.73	Apache/2.4.58	caddy/2.7.6
ab -c 50	92944.58	123365.41	124046.39	106615.49	92842.75	46338.77	38366.36
ab -c 100	94345.85	120250.12	121654.5	105412.96	90651.97	45797.61	38107.58
ab -c 250	89390.27	105693.72	106805.66	99929.05	87581.01	45026.18	36292.24
ab -c 500	76104.66	88635.2	89766.61	88397.79	82109.9	42196.05	34878.33
ab -c 750	69969.7	81203.76	81240.71	80171.25	74577.33	39665.23	33404.04
ab -c 1000	65129.18	74870.47	75520.14	74467.93	73565.65	38595.88	30630.78

jquery.js

This target is a medium sized 89.7kB file with sendfile support disabled, this is primarily a disk bandwidth test. The low results compared to all the other servers are are still a work in progress.

test	hinsightd/0.9.20	hinsightd/0.10 unpatched	hinsightd/0.10.2	nginx/1.25.3	lighttpd/1.4.73	Apache/2.4.58	caddy/2.7.6
ab -c 50	3210.75	26010.78	23656.27	34926.93	34674.42	30386.36	29233.18
ab -c 100	12762.0	25267.33	23560.4	31371.56	32054.57	26297.66	28916.61
ab -c 250	11118.68	25201.93	24729.22	30492.17	32994.04	24009.72	27589.63
ab -c 500	9625.7	23997.79	24807.19	29544.02	32963.92	22820.63	25792.07
ab -c 750	9319.79	21840.07	24299.03	28783.02	29456.56	21854.96	24772.4
ab -c 1000	9253.43	20960.05	22934.04	27815.02	28395.05	21859.79	23612.47

compressed jquery via gzip

Finally a worthy test of the new multithreaded capabilities of the new 0.10 branch. In the previous post we tried to benchmark ssl connections but that didn't give good results on a single computer so this is a replacement benchmark where we correctly test the server not the benchmark program.

Here we test dynamic gzip requests, the server should grab a medium sized file off the disk, apply the same cpu intensive algorithm and then respond. Because the time it takes to apply the gzip algorithm is several times longer than any other processing we're basically testing hdd bandwidth with a CPU bottleneck.

As expected most servers are showing horizontal lines. The weak results of hinsightd 0.9.20 are not worrying because we're running on a 4 core machine and as noted hinsightd/0.9 is single-threaded only but it's outputting straight horizontal lines which is good.

We had to enable multiple workers for lighttpd despite it being advised against otherwise the line wouldn't wiggle as much but it would be right next to the single-threaded hinsightd v0.9 line. Single threaded servers are really not suited to this kind of test.

And no the hinsightd/0.10 unpatched isn't 10 times faster than the other servers that's just a bug left in for reference.

test	hinsightd/0.9.20	hinsightd/0.10 unpatched	hinsightd/0.10.2	nginx/1.25.3	lighttpd/1.4.73	Apache/2.4.58	caddy/2.7.6
ab -c 50	270.44	1106.35	727.16	973.17	822.39	880.28	795.4
ab -c 100	269.26	1098.19	702.17	975.11	727.86	878.18	806.48
ab -c 250	267.51	1153.42	722.49	953.28	552.99	870.89	802.6
ab -c 500	262.42	1290.8	728.32	965.61	621.38	860.48	812.53
ab -c 750	258.7	1622.57	737.46	956.14	578.91	855.3	811.1
ab -c 1000	254.25	2265.3	726.06	930.04	372.22	844.06	811.74

Conclusions

Performance is very ticky to measure because you have to double check and doubt all of your results or you end up knowing less than you knew before you started. If you're interested in more you can check out parts I, II, III or IV of the benchmarks series.

Notes:

1. hin no patch means commit d0ec626012a2c9bb1edbb4b5c1349cc9da582632 a version prior to fixing the bug mentioned in the post.
2. tests were ran on a 4 core machine with no hyperthreading. hinsightd 0.10, nginx and lighttpd have 4 workers/threads enabled the rest are left at the default.
3. tests are run several times for each concurrency level and only the highest result is taken into account.
4. nginx config, lighttd config, caddy config, the apache2 config is too long to post but it's using worker mpm with ThreadsPerChild 64 before we were using event mpm with the default settings.

Hello this is another set of benchmarks of the hinsightd webserver. Again hinsightd v0.10 is a multithreaded server and the current branch under active development while hinsightd v0.9 is a singlethreaded server with more features but also more bugs.

What we test here is how fast the server responds to increases in concurrent connections. While this is not a perfect metric for servers, a webserver that can respond to more requests in a given time period is not only more likely to resist a DDoS attack but you can also add more processing per request before the delays become noticeable. Please consult a full list of features before deciding which webserver to use for your own site.

index.html

Testing a small 102 bytes file. This tests how fast a server can open a connection, parse headers, and close the connection, nothing that impressive. But it should be noted the multithreaded branch is the fastest server tested.

test	hinsightd/0.9.19	hinsightd/0.10.1	nginx/1.25.3	lighttpd/1.4.72	Apache/2.4.58	caddy/2.7.5
index.html -c 50	93850.01	127296.1	117020.65	56887.03	40069.56	37654.71
index.html -c 100	95571.23	121204.78	114876.51	56396.17	41065.91	36727.71
index.html -c 250	90076.29	106621.17	106724.72	53473.93	38698.64	35235.71
index.html -c 500	78003.12	91496.33	91003.4	50046.54	35879.2	33626.33
index.html -c 750	71083.31	83508.7	82136.87	50651.63	35209.66	32187.05
index.html -c 1000	66276.52	77152.16	76078.6	48633.87	33906.01	31376.68

jquery.js

For a more realistic test, the current jquery library, a 89.7kB minified js file. Unfortunately my server doesn't support sendfile so to make the test 'fair' I've disabled it across the board. I actually believe without sendfile this is a more realistic benchmark because in the web development world of today you rarely have unencrypted or uncompressed connections. This should test how fast a server is able to get data from the disk and push it to the http client with minimal changes.

In previous benchmarks (and in the 0.9 branch) the lack of TCP CORK flag really slowed down everything, adding support for it vastly improved performance but it's still under other servers. Further research and optimization needed.

test	hinsightd/0.9.19	hinsightd/0.10.1	nginx/1.25.3	lighttpd/1.4.72	Apache/2.4.58	caddy/2.7.5
jquery.js -c 50	2103.32	28276.54	36029.15	18746.64	26397.06	28822.85
jquery.js -c 100	3288.06	27483.85	32395.48	18618.75	27594.5	28424.11
jquery.js -c 250	5974.85	25550.88	31045.68	18116.5	24566.16	27583.62
jquery.js -c 500	10033.39	23537.39	30233.58	17595.81	23997.39	26233.43
jquery.js -c 750	10200.92	21585.31	29622.17	17745.63	23632.95	25614.69
jquery.js -c 1000	9777.69	21598.88	28680.33	17556.98	23047.9	24684.84

index.html via ssl

While I would like to benchmark SSL connections, previous tests proved that without a secondary machine this is impossible, testing SSL connections is very CPU intensive so without another machine it just tests how fast the benchmark software can create connections on a CPU bottlenecked system, not very useful data.

If you find these tests useful a more comprehensive set of tests and benchmarks is include with the source code in the external/tests directory.

Notes:

1. tests were ran on a 4 core machine with no hyperthreading. hinsightd 0.10.1 and nginx have 4 workers/threads enabled the rest are left at the default.
2. tests are run 6 times for each concurrency level and only the highest result is taken into account.
3. both hinsightd branches are using the current HEAD.
4. nginx config
5. lighttd config
6. the apache2 config is too complicated to post, but it's the distribution default.
7. caddy config