←back to thread

Serving 200M requests per day with a CGI-bin

(jacob.gold)
166 points feep | 1 comments | 04 Jul 25 13:16 UTC | HN request time: 0.205s | source
Show context
simonw ◴[04 Jul 25 14:30 UTC] No.44464893[source]▶
I got my start in the CGI era, and it baked into me an extremely strong bias against running short-lived subprocesses for things.

We invented PHP and FastCGI mainly to get away from the performance hit of starting a new process just to handle a web request!

It was only a few years ago that I realized that modern hardware means that it really isn't prohibitively expensive to do that any more - this benchmark gets to 2,000/requests a second, and if you can even get to a few hundred requests a second it's easy enough to scale across multiple instances these days.

I have seen AWS Lambda described as the CGI model reborn and that's a pretty fair analogy.

replies(3): >>44465143 #>>44465227 #>>44465926 #
geocar ◴[04 Jul 25 15:10 UTC] No.44465227[source]▶
I think you might have found that CGI scripts deployed as statically-linked C binaries, with some attention given to size, you might've not been so disappointed.

The "performance hit of starting a new process" is bigger if the process is a dynamically-linked php interpreter with gobs of shared libraries to load, and some source file, reading parsing compiling whatever, and not just by a little bit, always has been, so what the author is doing using go, I think, would still have been competitive 25 years ago if go had been around 25 years ago.

Opening an SQLite database is probably (surprisingly?) competitive to passing a few sockets through a context switch, across all server(ish) CPUS of this era and that, but both are much faster than opening a socket and authenticating to a remote mysql process, and programs that are not guestbook.cgi often have many more resource acquisitions which is why I think FastCGI is still pretty good for new applications today.

replies(1): >>44465544 #
simonw ◴[04 Jul 25 15:48 UTC] No.44465544[source]▶
That's likely true - but C is a scary language to write web-facing applications in because it's so easy to have things like buffer overflows or memory leaks.
replies(7): >>44465786 #>>44466009 #>>44466418 #>>44467031 #>>44470699 #>>44470836 #>>44477576 #
1. ryao ◴[06 Jul 25 03:26 UTC] No.44477576[source]▶
If you use secure string functions, you can generally avoid buffer overflows in C. The problem is that not everyone does. That said, exploiting buffer overflows in programs whose source code and binaries are not public is very difficult. It likely can be done, but most people would likely go after easier targets. If you deploy AddressSanitizer in production, you can get the program to terminate whenever a buffer overflows occurs, at the expense of additional overhead when there is no buffer overflow.

Memory leaks are considered a feature in short lived programs, since not freeing memory in favor of relying on the kernel to free it at program exit lets them run faster.