Hacker News Reader

Comment by geocrasher | Hacker News Reader

I have yet to try running this for anything, but I do appreciate how it really sticks to the "do one thing well" ethos. Modern web servers can be extremely complicated with a lot of moving parts. This boils it down to just one thing and lets a person focus on the project instead of the infrastructure. Granted, it's very simplistic, but that's its strength.

View on HN

I do respect the technical chops around sqlite. However, I think a "fork for every single http request" server isn't really useful in many situations.

That the sqlite website is able to run this way is more a testament to Linux's work on a lightweight/fast fork() than anything else. This would perform terribly on a more traditional Unix.

I ran a webmail service with 2m users that forked and exec'd a CGI for every request 20 years ago. 20 year old hardware was already fast enough that we were usually IO bound on the storage backend rather than constrained by the (much cheaper) frontends.

Forking for every request is slow, sure.

But if your code is written with it in mind it's faster than most people might expect, and most people never get to a scale where it matters.

It's not the right choice for everything, but people have ironically gotten obsessed with things we introduced a long time ago as workarounds for slow hardware (and fork used to be slow on Linux too) decades after the original problems were largely solved.

I do agree there are times this won't be useful, though.

"I ran a webmail service with 2m users that forked and exec'd a CGI for every request"

Yes, but that met expectations of that time period, and expectations for a webmail service. I'm curious if you also forked for every static asset...that's what this setup appears to do.

I just don't see the benefit of mysql choosing to use this today. It works, but there are other minimal http servers that would be just as simple, but would be faster and use fewer resources. I suppose they don't need to change it, but it's not really a great example of anything other than "fork is cheap on linux" to me.

Performance expectations were if anything for the most part tighter than what people tend to get away with today. People hadn't gotten used to slow dynamic sites yet.

We didn't fork for for every static asset, but the vast majority of overall requests were dynamic past the initial pageload, so the vast majority of requests resulted in fork.

In terms of benefits, the simplicity is attractive. It's an approach that is in general quite resilient to errors.

> Yes, but that met expectations of that time period,

As peer poster said, expectations years ago were higher than today. It is frustrating how common it is for sites to think that downloading multiple MB of code just to show a simple page and having it take seconds to render is somehow ok.

The expectations used to be ~100ms for a page load and render back when I was working on high performance web servers (~15 years ago).

What are your thoughts on darkhttpd?

https://unix4lyfe.org/darkhttpd/

Never used it, but it says:

- Uses sendfile() on FreeBSD, Solaris and Linux

- Event loop, single threaded - no fork() or pthreads

- Supports If-Modified-Since, Keep-Alive, IPV4, 301 redirects

And appears to be just a little larger than Althttpd. Sounds good to me.

But pretty much nobody is is running a more traditional Unix nowadays. Almost everyone uses Linux for web servers. So let's judge the tool based on its actual context, not on an unrealistic one.

I'm saying it's not terribly interesting or broadly useful, unlike the rest of sqlite, which is. There are other minimal http servers that are vastly more efficient without being much more complicated.

Reply on news.ycombinator.com