Overview
ZFPM (Zone FastCGI Process Manager) is a software product developed by Zone Media whose mission is to provide an automated, scalable and secure way to run FastCGI based applications in virtual server environments.
ZFPM is primarily a process manager for PHP applications, but it can also handle other FastCGI applications (e.g. Ruby On Rails, Django).
Since security is our first priority in a shared environment, it is not feasible to run applications with web server privileges, as is the case with mod_php (DSO). PHP in FastCGI mode allows each virtual server to run its applications with user privileges.
The ZFPM-based system has two main components:
- ZFPM – FastCGI process manager
- mod_zfpm – Apache2 module for FastCGI queries – optimised specifically for ZFPM
mod_zfpm‘s job is to send the incoming HTTP request to the ZFPM, which if necessary will launch and forward to the correct PHP-FCGI application. PHP-FCGI generates a response (web page) and sends it back to ZFPM, which in turn sends it to mod_zfpm, and finally to the client that initiated the request. Data transfer between all three components (mod_zfpm <-> ZFPM <-> PHP-FCGI) is done using the FastCGI protocol.
As an alternative to ZFPM, it is possible to use the mod_fcgid and mod_fastcgi Apache modules, whose process managers are rigidly integrated into the Apache web server process. Hence the important difference with ZFPM, which manages all FCGI processes completely separately from the Apache web server. This means that the initial loading of the web server software does not interrupt or directly affect the running PHP scripts. Scripts are able to complete their work uninterrupted, regardless of the fact that, for example, the configuration of the web server has changed during the work and the software has been initialised. Also, not all PHP-FCGI processes are stopped/started during the initial loading of the web server.
The number of PHP-FCGI processes on a server under load can be in the thousands, and it would be extremely irrational and inconvenient to bootload such a large number of processes simply by making a small change to the configuration of the web server.
Since ZFPM is a universal tool for everything that speaks FastCGI, there is no problem running applications based on different versions of PHP simultaneously on virtual servers. Another alternative to ZFPM can be mentioned here – PHP-FPM, which is a PHP-specific FastCGI system only. However, its main drawback is the complexity of securely managing PHP-FCGI processes, especially in a shared environment where there may be thousands of different virtual servers on a single physical server, which must be able to run different versions of PHP as desired.
Descriptions of the most common errors
While FastCGI is one of the fastest and most secure ways to run PHP in a shared environment, it is (unlike simple mod_php) a rather complicated query processing chain, where failures in various components can result in a variety of sometimes cryptic messages in the Apache error_log.
Below are some of the more common ZFPM error messages and some hints on how to start looking for the cause of the error.
Connection to FastCGI was reset by peer during reading response. Check your FastCGI application log. Increase LogLevel verbosity to 'info' for additional protocol info.
The first thing to do is to check the log file of your application, as it is likely that the application has unexpectedly stopped working and closed the FastCGI connection. The client will receive an HTTP 500 error message. If you are unable to determine the cause on your own, you should contact technical support and find out how to reproduce the error.
stderr: Timeout (30s) exceeded while waiting for FCGI process to become available
The limit of PHP-FCGI processes running parallel requests on this virtual host has been reached and the request has been waiting for at least 30 seconds behind some process release without results. The client receives an HTTP 500 error message. This is likely to be a website under significant load, so if the problem occurs frequently, it is advisable to seek resolution through technical support.
stderr: Timeout (900s) exceeded while reading from socket (application)
The application has been processing the request for at least 15 minutes without sending a response. The script should output something from time to time, otherwise the process manager will assume that the script is “stuck” somewhere and forcefully abort it. It is also worth noting that the maximum time to process a web request is 86400 seconds, and if this is reached, the script will be aborted regardless of whether or not it is outputting anything. If HTTP headers have already been sent, the response will be interrupted half way through. If not sent, the client will receive an HTTP 500 error message.
stderr: Timeout (150s) exceeded while reading from socket (server)
The HTTP client is sending the request too slowly. In this example, it has not been able to send any new bytes in 150 seconds. The process manager aborts the wait and the client receives an HTTP 500 error message.
stderr: <Error reported by PHP script>
Error messages from scripts that are not caught by the script itself are passed by PHP-FCGI to the web server. Such error messages are displayed directly in the error log.