[Chugalug] FastCGI vs Apache's PHP engine ?

flushy at flushy.net flushy at flushy.net
Fri Oct 11 17:03:25 UTC 2013

Quoting Rod <rod-lists at epbfi.com>:

> What are the pros and cons of each approach?

from what I remember...

CGI used to be out of process: ie, the web server had to do a context  
switch by forking the process, execv() the cgi and communicate via  
pipes. This, however, has several benefits, one of which is process  
isolation -- your CGI can bomb and it won't affect your web server.  
The downside is that all those shared libraries and initialization  
need to be done for every invocation (request). Using specialized SUID  
wrapper programs, you can configure your CGI to run as a different  
user: apache-httpd can run the accounting cgi program as Bob.

Apache Module:
PHP initially was implemented as a CGI, till Apache's 2.0 modules came  
out. Then PHP was handled in-process via a thread by a module  
(dynamically loaded library). This meant that there was less context  
switching, however, since it was a thread and not a new process, this  
mean the PHP app-space could technically corrupt the Apache server's  
app-space -- since they were the same space. Also, this means that  
whatever user the Apache server is running as, is also the user that  
the PHP script will run as. These risks were overshadowed by the  
increase in speed due to the lack of context switching and forking.

Enter FastCGI.

Fast CGI handled the issues with CGI by using a native module  
(dynamically loaded library) of the web server that keeps a  
communication stub in-context with the web server.

The communication stub then forks off whatever "fastcgi" applications  
you have configured as long-running processes. There are various  
configurations of this. The simplest version is like a perl script  
that basically loops:

while (FCGI::accept >= 0) {
# body of response loop

As long as fastcgi is configured to send requests to that script, that  
script will run forever and continue to process requests. You can  
configure multiple "children" to handle multiple request loops. I'm  
sure they do some nifty thread tricks now, but I'm not up-to-date on  
those (I just assume they've migrated to that). There should also be  
API's to communicate back to the parent FastCGI stub thread that lives  
inside the web server's app-space. Thus, modern implementations should  
give you the same flexibility that Apache modules would give you --  
granted, it might be slightly more complex to call (just an assumption).

What this does solve three things:

* context switching: initialization, process creation and shared lib loading
* process isolation
* FastCGI processes can run as a DIFFERENT user than the web server

so you in effect, get the best of Apache modules AND CGI.

The risk, however, is that it's slightly more complex to configure. By  
extension, this means it might be slightly more complex to  
troubleshoot. However, it's been around for YEARS, and therefore,  
there is A LOT of support data out there if you search for it.


More information about the Chugalug mailing list