It's unusable today, more so than it was a decade ago:

- modern frameworks have a much higher startup time (see Python imports, Java VM and other). CGI was fine to run a perl script with no dependencies.

- it prevents any form of caching. caching is very important for many use cases.

- it requires to open a fresh connection with every request, to the database and elsewhere (too bad if you thought you could use redis for caching).

- SSL is everywhere and it has a notable overhead on initialization, meaning you really wish you could reuse connections. (Not just the databases but to other API services)

Speaking from experience, I've inherited the CGI platform at JP Morgan (the largest US bank), that went back to 2006 and approached a thousand running applications at some point. It works and it was still the easiest way to deploy any application in 5 minutes 2 decades later but the drawback are real. It's only for short scripts that can tolerate a 5 second startup time and zero caching.

https://thehftguy.com/2020/07/09/the-most-remarkable-legacy-...

Wait a minute, how CGI is preventing anyone from reusing connections? The web server doesn’t have to cut connections between CGI requests, the same way it doesn’t have to cut connections between the delivery of two different static files.

Maybe current web servers are written in such a way that they do cut connections between CGI requests, but I’d be surprised if they really have to.

They aren't talking about client->server connections but about server->DB or server->other server connections.

With CGI, any connection you create in your script is going to close at the end of the request when your process shuts down.

> prevents any form of caching. caching is very important for many use cases

There are alternatives; even back in 2000 you'd keep the stuff you wanted cached in the filesystem, where the webserver would handle the cache headers for you, and there are ways to hook a cache miss by the webserver to generate content on demand.

>- modern frameworks have a much higher startup time (see Python imports, Java VM and other)

That's fine, they can keep. TFA suggests using CGI in lieu of modern frameworks, not WITH modern frameworks.

>- it prevents any form of caching. caching is very important for many use cases.

No, it really doesn't. You can cache whole responses with a reverse proxy on top, or you can cache complex results in whatever (Redis, disk, etc) and query it from the CGI program.

>- it requires to open a fresh connection with every request, to the database and elsewhere

Which might be fine. MySQL for example is notoriously cheap to connect to for each request. Redis as well. (And you can always bump CGI to FastCGI).

>- SSL is everywhere and it has a notable overhead on initialization, meaning you really wish you could reuse connections

You can terminate SSL on your proxy, so that's not a issue.

> it prevents any form of caching. caching is very important for many use cases

> it requires to open a fresh connection with every request, to the database and elsewhere (too bad if you thought you could use redis for caching).

nutcracker, twemproxy?

apache caching reverse proxy even.

From context i assume the poster meant object caching, since the cgi model wouldnt affect client caching or cdn style front-end caching.

The problem has got worse rather than better; the machines are approximately 1 million times more capable in terms of raw MIPS, but the runtime startup cost of the languages used has increased, so the wall clock time to start a request has gone up.

2000 era CGI tended to be in Perl or PHP. Even then Java made an appearance, with a long-lived host process, e.g. Websphere.

One advantage which the author gets right is that CGI consumes no resources while not serving requests, so you can have a lot of different CGI programs on the same machine. It also plays nicely with multi-user systems, so an ISP could host a lot of different customers on one box. We could serve CGIs from several hundred users off a 128MB Pentium system, for significantly less resources than one Slack instance.

There are modern options with really quick startup speeds though, like LuaJIT or compiled Rust.

Fastcgi maybe? It's a little more complex but doesn't spawn process like cgi

Its also generally how php is deployed when not using apache, so it clearly does scale.

Forking a new process for every incoming web request might just make a lot of sense on ~2020 era, Spectre- and Meltdown-prone hardware. And so the Wheel of Samsara turns.

The threat posed by Spectre and Meltdown cannot be mitigated by just switching to a multiprocessing architecture. The threat is exactly about bypassing that abstraction too.

What are typical process creation times nowadays on Linux?

I see that starting up a Python interpreter and running a Python program (or Ruby or whatever…) might be slow, but how far can I get with a golang, C or ocaml binary?

I don't know, but I'd expect the Linux people to have optimized that to death.

I use CGI all the time. But I’m not trying to serve 2000 users a minute.