FastCGI – The Forgotten Treasure (2002)

It works on Dreamhost, but it takes some effort.

FastCGI provides that but the Python libraries are not that well documented, and sometimes unmaintained. For some reason this appears to be a "cultural" thing and not a technical issue.

I wrote a whole bunch of comments about my plans to work on that here (andyc):

https://lobste.rs/s/xl63ah/fastcgi_forgotten_treasure#c_65gp...

I'm probably going to share my .wwz Python WSGI/FastCGI script. And show the hacks I did to deploy it on Dreamhost.

Long term I want to build FastCGI support into https://www.oilshell.org/ so the same problem doesn't exist there! i.e. the fact that you CAN deploy Python on many shared hosts, but nobody does because the ecosystem doesn't support it. Whereas the PHP ecosystem does support it, but the language is hard to learn.

I don't remember if there was any other option on the server we had, but I had to write that sucker in C! Reading and parsing a .csv file, handling search options, working as a CGI program, what a pain, especially for a dumb high schooler like me!

Isn't this what most people use their phone for? What exactly are you compromising on in this list? You might as well say you just need a fully-functional smartphone, not a hacking project.

Although, now that I understand fastcgi better, I guess fcgiwrap could be adapted for lighttpd, if it doesn't work for it as is (my package manager's description mentions explicitly it's for nginx).

Thanks for the advice, I'll dig that.

> The thing that fastcgi brought over cgi-bin was that an application process could be left open to communicate with the server, where-as cgi-bin model required spawning a new process for each request.

Absolutely (I read/skimmed the article, and this was brought up) -- serverless functions are the same here, because it also allows for machines to stay running for some indefinite

> If one reads the AWS Lambda docs, they'll see the execution context[1] has a similar behavior. AWS will spin up new instances, but these instances will serve multiple requests, via a fairly custom "function" interface defined for various runtimes (but which is actually, typically an http interface). There is a standard HTTP api for runtimes to use to retrieve function invocations[2].

> With FastCGI the front end server uses a socket to push request messages to app servers, which replies in order. Where-as with Lambda & it's above mentioned runtime API, the runtime is retrieving requests from Amazon at it's pacing, & fulfilling them as it can. So there's a push vs pull model, but in both cases, the application server is talking a fairly custom protocol to the front-end server.

This is one of the reasons I said "serverless functions" instead of Lambda. While AWS happens to specify their operational semantics that way, there is no need for anyone else to. While improvements are necessary I still think this is fairly close to FCGI, and FCGI could absolutely serve as a "serverless" provider implementation.

Needless to say, how long you keep around the process, or how you checkpoint restore (criu[1] is very interesting, for anyone who's never seen it) and move processes are all implementation-specific in my mind.

[0]: https://gitlab.com/mrman/talks/raw/master/dist/2019/04/merca...

[1]: https://criu.org/Main_Page

HHVM as you mentioned lost momentum when PHP7 largely met or surpassed its performance. That’s not a bad thing though, it just wasn’t hugely necessary anymore. The major upside is everyone gets the boost now, whereas HHVM was a nightmare to setup if you were not Facebook.

Beyond that, I truly believe the stateless nature of PHP requests is by far the easiest mental model to work with. As cross-request state is held exclusively and explicitly elsewhere (Redis, Memcache, SQL), it’s remarkably easy to reason about at scale.

This makes it easy to scale! Just throw another server on the load balancer and everything works. I work on a relatively large educational product, and we auto-balance up to 30+ servers during the week to handle a couple million users sending continuous streams of data, down to a minimum of 2 on weekends. It’s taken almost no consideration on the developers parts because of PHPs naturally stateless clean slate per page load model.

We also have a fair bit of Go in production, largely for CPU intensive operations. I love Go and use it for the majority of my newer personal projects. The major advantage to PHP that keeps it our primary language is the speed at which I can develop and iterate. The difference save/refresh vs save/recompile/restart/refresh makes in speed is not to be underestimated.

Myself as well as our lead dev have been using Go since before 1.x and we both still agree that PHP is better for rapid prototyping as well as just generally getting things out the door quickly.

This server isn't directly exposed, only valid requests are proxied to it.

I have no reason to think this is the best approach, it's a near forgotten foundational layer of an application that has been stable and reliable for a decade, that is under constant attack and regularly pen-tested.

Or if you're running PHP, this shortcut usually does the right thing: https://caddyserver.com/docs/caddyfile/directives/php_fastcg...

You also have less control over buffering and since you don't see the actual connection, you have to rely on special headers to get things like remote ip and remote protocol. Not a big deal, but still nice.

Apache's FastCGI support was atrocious until mod_proxy_fcgi arrived only a few years ago. This severely limited FastCGI adoption in Apache territory. But sometime in the mid-00s lighttpd came along, and then nginx. Both of them not only supported but required FastCGI to interface with PHP. So the lighttpd guys developed spawn-fcgi, which was a huge step ahead of Apache's mod_fastcgi/mod_fcgid. With the increasing popularity of nginx, PHP itself adopted FPM (FastCGI Process Manager), which went yet another step ahead of spawn-fcgi. The performance gains were unbelievable! That was sometime between 2006 and 2008 IIRC, just when PHP was starting to clean up after itself.

PHP-FPM is now the preferred way to run PHP no matter what webserver you use (perhaps with the exception of IIS). It keeps things running fast and smooth without giving up PHP's straightforward, CGI-like execution model.