Separating Apache and PHP has some advantages. Faster delivery of non-PHP content, lesser load on the servers to name just the most obvious ones. That’s why you can find this kind of setups mostly at smaller ISPs. To really benefit from the separation of Apache and PHP, however, you’d need to move PHP to completely seperate servers.
That’s where
comes into play. In theory this Apache configuration directive allows you to specify an external server where all requests for PHP scripts (or any other resources you define) will be sent to. But where you’ll find plenty of documentation about how to install a FastCGI server on the local machine, the documentation about how to use an external server is almost non-existant. And the official documentation doesn’t really help and neither does the FAQ. Or would you find this helpful:
What is the path used with FastCGIExternalServer?
Since all FastCGI directives are global (they are not configured in a server context), all FastCGI paths map to the filesystem. In the case of external servers, this path does not have anything to do with the file system; it is a virtual file system path. Since the connection between mod_fastcgi and the FastCGI app is by a socket (unix or tcp), mod_fastcgi does not care where the program is (it could be on a completely different machine). However, mod_fastcgi needs to know when a hit is calling for an external app, so it uses this path as if it were a local filesystem path. Apache translates a request URI to a filesystem path.
Most ironcally, it’s exactly the path mentioned above that causes most users to give up on
. Ok, so let’s get our hands dirty. Follow me into the abyss of weird logic and software bugs to finally get your external PHP server up and running. On the way you’ll learn that nothing is as it seems and that the FAQ entry quoted above is misleading at best.
Pingback: External FastCGI With Apache « IT Know-It-All