3 ms·

I think the word you're after is latency, because scalability isn't the issue. CGI-hosted web apps tend to use fronting HTTP caches plus memcache-like distribut

I think the word you're after is latency, because scalability isn't the issue. CGI-hosted web apps tend to use fronting HTTP caches plus memcache-like distributed caches or RDBMSs for app data once a request has actually resulted in a process being spawned. Historically, what's slow about pure CGI/process-per-request architectures are dynamic language runtimes that need to parse the entire CGI implementation code for each request (like old mod_php/mod_perl). That source of slowness can entirely be eliminated by using natively compiled CGIs. IMO FastCGI, or any other architecture inviting huge long running userland processes without GC, always end in robustness problems, memory fragmentation and grave security issues due to lack of process isolation, and still have about the same overhead as process creation in process-per-request architectures. What may help is a way to supply CGI params (PATH_INFO, QUERY_STRING, etc.) not via environment variables, but via eg. sockets, such that a number of pooled CGI processes can be started ahead of time, before a request is coming in.

vidarh 6y ago
Indeed we ran a ~2m user webmail service as a CGI written in C++ ~20 years ago. We addressed latency aggressively by statically linking and never explicitly freeing memory except if we really had to - the processes were short lived; better to let the OS just dispose of everything at once. The process overhead was not a big deal even on 20yo hardware, and it saved us from dealing with all kinds of awful isolation issues. We discussed fastcgi or the like and dismissed it because the latency savings were much smaller than one might expect exactly for the reasons you mention: The problem was much less the process creation overhead than the overhead of dynamic runtimes. People also seem to have forgotten what was expected back then. The time it takes to load Gmail for example would have been totally unacceptable. Our biggest latency limitation was not the web server / CGI, but optimizing the mail storage backends, so that is where we spent our effort.

vidarh 6y ago

Indeed we ran a ~2m user webmail service as a CGI written in C++ ~20 years ago. We addressed latency aggressively by statically linking and never explicitly freeing memory except if we really had to - the processes were short lived; better to let the OS just dispose of everything at once. The process overhead was not a big deal even on 20yo hardware, and it saved us from dealing with all kinds of awful isolation issues. We discussed fastcgi or the like and dismissed it because the latency savings were much smaller than one might expect exactly for the reasons you mention: The problem was much less the process creation overhead than the overhead of dynamic runtimes. People also seem to have forgotten what was expected back then. The time it takes to load Gmail for example would have been totally unacceptable. Our biggest latency limitation was not the web server / CGI, but optimizing the mail storage backends, so that is where we spent our effort.