Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Althttpd: Simple webserver in a single C file

sqlite.org

Post reply on HN
Print view View original

141–150 of 345 posts

Re: Althttpd: Simple webserver in a single C file

#141

Post by michaelmior »

mbreese wrote: post #70
secondcoming wrote: post #57

Earlier quoted context omitted.

Being text based is a huge flaw with HTTP in my opinion (and also elsewhere, like Redis). It leads to parsing bugs and overly verbose communications. Humans are good at reading text, CPUs prefer binary.

The use of text for popular protocols is for a reason — computers don’t write programs, people do. And while CPUs prefer binary, it’s easier for programmers to read/write/reason about text. This makes it easier to work with a new protocol. From a practical perspective, with a binary protocol, it can be difficult to use across different languages or add support for a new language. If you use the simplest possible enco…

Except it quickly gets messy when you start dealing with real data and making sure encoding and escaping is done correctly.

> with a binary protocol, it can be difficult to use across different languages

This is also true of text protocols that aren't well-designed. I don't think it's necessarily the case that binary protocols are more difficult to deal with. You just have a different set of concerns to address.

> If you use the simplest possible encoding, you’d send raw struct data.

This is the "simplest" in the sense that it's definitely easy to just copy this data on the wire, but I think this is a straw man. I don't think it's really any more difficult to write a simple protocol that uses binary data compared to text.

Re: Althttpd: Simple webserver in a single C file

#142

Post by brundozer »

pdimitar wrote: post #100
henvic wrote: post #91

Take a look at Fossil too: https://www.fossil-scm.org/ It's the distributed version control (and more) used by SQLite. Most people have no idea about how cool the SQLite ecosystem is, and how it's used even on avionics!

The lack of ability to squash PRs into single commits is a deal breaker for many, myself included. No, having a commit "fix typo" in the main branch's history is not at all useful and won't ever be. It's noise. In a work setting it's much better to reduce noise.

I agree with you that such a commit has nothing to do in the main branch. But it has nothing it do in any branch that is shared with anyone either. Git has enough ways to keep your own history clean at all times to not require a hack like squash PRs to compensate the lack of discipline of a team. With squash PRs you lose so much valuable information that it gets impossible to use commands like bisect or to have a proper context on a blame.

Re: Althttpd: Simple webserver in a single C file

#143

Post by jiofih »

wongarsu wrote: post #77
cube00 wrote: post #35

> A separate process is started for each incoming connection, and that process is wholly focused on serving that one connection. It makes you wonder just how "heavy" operating system processes actually are. We may not need to worry about the complexity of trying to multiple run async requests in a single process/thread in all cases.

Apache's thread-per-connection model used to run basically the entire internet until nginx came along and demonstrated 10k simultaneous connections on a single server. If you only have around 100 concurrent confections, a separate thread per connection is entirely feasible. A whole new process is probably fine on Linux, but e.g. Windows takes pretty long to spawn a process

You might want to review that knowledge. You can spawn a few thousand threads on a modern machine without much contention.

Re: Althttpd: Simple webserver in a single C file

#144

Post by jiofih »

sydthrowaway wrote: post #61
cube00 wrote: post #35

> A separate process is started for each incoming connection, and that process is wholly focused on serving that one connection. It makes you wonder just how "heavy" operating system processes actually are. We may not need to worry about the complexity of trying to multiple run async requests in a single process/thread in all cases.

So what was the point of the async/callback web programming revolution if processes were good enough?

Memory use. Even though threads / processes are “cheap” right now, it wasn’t the case in the past and they are still quite far from the couple-of-kbs per connection needed in async servers. You’re not getting a million paralel processes processing requests any time soon.

Re: Althttpd: Simple webserver in a single C file

#146

Post by geocrasher »

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.

Re: Althttpd: Simple webserver in a single C file

#147

Post by dspillett »

iveqy wrote: post #44

I thought forking webservers was too slow?

It depends how complex a process you are forking and what OS you are running on. It has been some time since I wrote any real code for Linux or Windows that would be significantly affected by such things, but it used to be that forking could be almost as efficient under Linux as starting a new thread in an existing process. Under Windows this was very much not the case. Threads make communication between parts easier (no IPC needed) but that isn't usually an issue for the work a web server does.

Comparing to purely event based web servers forking can still be better as no request should fully block another, or usually crash another (which is more likely with threads), and thread or fork based servers can make better use of concurrency which is significant for CPU heavy jobs.

So swings & roundabouts. Each type (event, thread, process, some hybrid of the above) has strengths, and of course weaknesses.

Re: Althttpd: Simple webserver in a single C file

#148

Post by azernik »

jiofih wrote: post #139
throwaway525142 wrote: post #110

Earlier quoted context omitted.

Squashing for example allows me to have a history where each commit builds. This has been very useful for bisecting for me. I wouldn't call it "next to nothing". The "greater detail" part can cost me a lot of time.

Having commits that do not build represents the history more accurately. It could very well be a “fix” to some build error that silently introduces an issue, that context is lost when you squash.

Representing the history more accurately is not a useful design goal

Re: Althttpd: Simple webserver in a single C file

#149

Post by lmilcin »

michaelmior wrote: post #133
throw0101a wrote: post #128

Earlier quoted context omitted.

I question the ascertain that humans were doing "GET /" or "HELO my.fq.dn" on any regular basis. There were mail clients from the very beginning for example: * https://en.wikipedia.org/wiki/History_of_email Perusing document-based information was also done via clients, first with Gopher and then with the WWW: either GUIs like Mosaic, or on the CLI via (e.g.) Lynx.

I definitely did back in the day :) But I'm only one single human.

I did both send mails over SMTP as well as downloading files from FTP using Telnet.

Re: Althttpd: Simple webserver in a single C file

#150

Post by ankurpatel »

Performance is really bad. This is good for running a small HTTP server on an embedded device but if plan is to use it for HTTP server to serve production web traffic performance is really bad. Below is report of running the server and hitting a minimal index.html page and hitting it with artillery.

All virtual users finished Summary report @ 09:39:57(-0400) 2021-06-08 Scenarios launched: 33645 Scenarios completed: 2573 Requests completed: 2573 Mean response/sec: 42.57 Response time (msec): min: 0 max: 9029 median: 2 p95: 6027.7 p99: 8778.8 Scenario counts: Get index.html: 33645 (100%) Codes: 200: 2573 Errors: ETIMEDOUT: 31008 EPIPE: 48 ECONNRESET: 16

Post reply on HN