I use FCGI with Go programs. FGCI is an orchestration system. Each worker process has a subroutine that's called when there's an incoming request, so the FCGI processes are reused for more than one task. The FCGI server will fire up more worker processes when needed, and ask them to exit when there's no work for a while. If a worker process crashes, a fresh copy is started. Every few minutes, each worker process is told to exit, so if you have a memory leak, the problem is contained.

Once you've switched to hard-compiled Go, vs. some interpreted language, you've obtained most of the possible speedups.

That's really all you need. I have a moderately busy server that's been up for over a thousand days without a reboot or restarting the FCGI service running under Apache.

You have to have a huge load before FCGI, multiple servers, a load balancer, and back-end database machines are not enough. Wikipedia used to run on something like that, until they hired too many people and had to keep them busy.

Why don't you use the golang http server instead?

I used to use FGCI with perl. I never thought it could improve performance of GO as handler routines are already "running".

So the remaining advantage to use FCGI with Go is that memory leaks would never be an issue?

We used fcgi at my last company in routers. When you make a request to a router's embedded webserver internally it forwards the request via unix sockets to a persistent CGI process which sends back the JSON. Worked really well and had a tiny memory footprint.

It's a bit better but one process can only process one request at a time. You need a lot more processes compared to a http framework processing http requests in parallel.

How do those web frameworks gain the ability to process things in parallel? What prevents a ‘single process’ from adopting those same methods?

Those web frameworks are lower level and have an embedded HTTP server designed to process things in parallel. It's in the standard library in golang or nodejs for example.

Sounds like one can use libuv in a CGI project and gain the same parallelization.

... and end up with something like Node.js or Vert.x.

Usually you have a thread pool (threads have startup costs too), monitor the server socket and assign incoming connections to one of the worker threads. Nonblocking architectures that do everything in a single thread also exist.

It's very common even to do this: just use Apache `mod_proxy` (or something more specialised) to forward requests to a backend server such as Apache Tomcat.

Most people don't need to worry about 'parallel' - that's the point of the OP.

Need a site to order XYZ? Unless you are a mega chain, small biz doesn't need to do anything more complex than serve its 100 customers reliably. Most 'modern' stuff is wasted abstraction for complexity which does not exist.

how many features can your process accumulate before it's called a framework?

Fcgi apps can handle requests in parallel in a single process just fine, as long your environment supports it.

You are right, fastcgi supports multiplexing. It seems that it's not implemented very often though.