CGI is one of those "simplest thing that could possibly work" tools: for every request to a specific url path, the webserver runs an executable. Headers passed in the environment, stdin and stdout plumbed to the network socket.
Back before serverless, we called it shared hosting.
Of course, fork() is not especially fast, so people came up with Fastcgi: persist the process and let it handle multiple requests. Then people started writing java where the startup time was prohibitive, and "application servers" like Tomcat came into being.
fork itself is pretty fast, relatively speaking (unless you have a large virtual address space and 4K pages or similar). fork+execve+process-runtime-initialization is much slower.
On my X201 (anno 2010), with 10000 iterations, sequential fork+exit(0)-in-child+wait takes:
$ /usr/bin/time ./forkfest
2,49 real 0,38 user 2,19 sys
while sequential fork+execve("/usr/bin/true",...)-in-child+wait takes:
$ /usr/bin/time ./forkfest2
10,99 real 3,10 user 7,94 sys
EDIT: also, My X201 is clocked at 1199 MHz (50%) for power saving reasons
On paged systems fork() is usually reasonably fast, but for CGI you do fork()+exec() and while exec() is also reasonably fast, the stuff that the happens in child process between it's start and entry into main() (ie. dynamic linking, libc initialization) is somewhat on the slower side. (Not to mention interpreter startup for interpreted languages)
Yes it's slower compared to a single multithreaded evented server, but that fork gives you process separation which is a huge security feature and resilient to one bad request taking down your whole server. You can aslo write your code blocking + single thread which is so simple and easy to debug
This seems to reinforce the brilliance of the Erlang VM. Basically, make "fork" super super cheap. Full process isolation, "let it crash" error handling, and lots of other benefits.
> Of course, fork() is not especially fast, so people came up with Fastcgi: persist the process and let it handle multiple requests.
FastCGI is a classic example of second-system syndrome. I once looked at the spec. It was ridiculously overdesigned. SCGI (Simple CGI) solves the same problem (reusing a server process for multiple requests), but its spec literally fits on two pages: http://www.python.ca/scgi/protocol.txt - It's also supported by nginx by default. (Don't know about Apache etc.)
And linking back to the topic, FastCGI was developed by Open Market, who sold a big ecommerce hosting system in the 1990s. It was written partly in Tcl and used Tcl format for writing structured logs.
> Back before serverless, we called it shared hosting.
You're right, but Windows was different. In Windows/Asp.Net land (which was a good chunk of shared hosting in the early 2000s), Shared Hosting providers were using AppDomains to isolate sites. IIRC, AppDomains were isolated by the .Net runtime rather than more robust process isolation.
Back before serverless, we called it shared hosting.
Of course, fork() is not especially fast, so people came up with Fastcgi: persist the process and let it handle multiple requests. Then people started writing java where the startup time was prohibitive, and "application servers" like Tomcat came into being.