Hacker News Reader

Comment by elvinyung | Hacker News Reader

I hate to be the young whippersnapper parrotting buzzwords, but CGI is theoretically supposed to lend itself really easily to deployment onto serverless runtimes, right?

View on HN

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.

> Of course, fork() is not especially fast

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

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

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)

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.

> 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.

> 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.

I'm actually working on this now: [1][2]

CGI was abandoned because of the slowness of process forking, but with modern kernels, new compiled languages, and better reverse proxy servers, I believe that the speed difference is trivial in regards to the advantages:

- Deployment can be done by simple file upload.

- Process isolation adds security and reliability.

- CGI scripts/binaries are vendor agnostic and can be run/tested locally

- CGI scripts can use any language, are stateless, promote hyper modular design (aka functions) and are generally minimalistic in nature.

[1] https://bigcgi.com/ [2] https://github.com/bmsauer/bigcgi

https://bigcgi.com/development - "Fast-CGIish Integration"

Are you thinking something like "FastCGI, except over stdin/out instead of a listening socket"? Since that sounds like it could work pretty efficiently if (unlike nginx's fcgi implementation) it supported multiplexing.

I think what I meant by that was basically building a generic FCGI wrapper that could automatically scoop up generic CGI scripts and run them in a shared process automatically. Like this: https://github.com/gnosek/fcgiwrap

I like the idea of communication via stdin/stdout though, I'll add that to my notes.

I actually was going to remove that from the roadmap entirely, because lately I really like the process isolation and statelessness of regular CGI.

Thanks for your comment!

Those first two points apply (almost) to PHP. Probably the nicest parts of it are ease of deployment, and the isolated “throw the world away” process model per-request. I’ve played with SCGI myself in Nim, it’s quite fun to explore.

After working all day deploying webservers in applications in containers in container management environments in virtual networks in virtual servers, its really nice just to drop files in a folder and update a webapp. I've always loved PHP for this, and that's basically what bigCGI is supposed to be about.

Ha! You know what they say, if we just add one more level of abstraction, all of our problems will be solved! Nobody will even have to know what's going on inside. Famous last words.

This was the best thing with PHP. In comparison, I spent most of Thursday digging through a problem with log4net which causes it to block all other web server threads if someone throws an exception and it has to do heavy reflection to generate the log message. This cascaded up into a complete process failure.

Shared state and locks are evil.

CGI predates serverless by quite a bit. It’s basically a standard interface for a web server to let any arbitrary executable handle a HTTP request.

https://en.m.wikipedia.org/wiki/Common_Gateway_Interface

Non mobile link: https://en.wikipedia.org/wiki/Common_Gateway_Interface

Is there a non-censored link? :-(

Here's one I found.

http://www.oreilly.com/openbook/cgi/ch01_01.html

How about this one? http://archive.is/1WmHz

Whats censored in that page?

Based on their profile, I gather they're referring to the fact that Wikipedia is blocked in Turkey.

https://en.wikipedia.org/wiki/2017_block_of_Wikipedia_in_Tur...

You can use use wiki zero mirror (www.0wikipedia.org sufficient to put a zero before any wiki link) until illiterate government of superstitious majority hopefully disappear.

+1 for the "0-prefix" tip; cool!

Thanks, also works when subdomain is different

I know that.

Yep, I've been thinking a lot about "serverless is pretty much CGI".

But actually, Lambda can keep your server open to serve multiple requests without spawning new processes all the time.

I realized that the key feature is not having the server open all the time, only when necessary. So I took systemd's socket activation idea and added socket deactivation, i.e. sending SIGTERM to the server after a period of inactivity: https://github.com/myfreeweb/soad

Plus, one of the things that really deserves more hype and popularity is CloudABI https://nuxi.nl an ABI that lets you have one binary that runs on multiple operating systems as is and always runs sandboxed.

The serverless runtime of my dreams just takes CloudABI binaries (packed with files in a tarball) that listen for HTTP on a given socket, and does the activation-deactivation thing to only run on demand :)

Easily yes, but I don't think it would be efficient. AWS Lambda, from what I can tell, doesn't launch a new process for each request; instead, it just "freezes" the process between each request, and then call a function to handle it.

In that regard, it's closer to FastCGI than CGI itself.

Reply on news.ycombinator.com