PHP FastCGI Process Manager daemons are widely used to host busy PHP-based websites. Read on to learn more about how to monitor these processes.
How Web Servers Handle PHP
PHP gets rendered, or executed, by a PHP interpreter. When your web server, like Apache or Nginx, needs to render PHP, it needs to invoke the PHP interpreter to actually perform the rendering. They need to hand off the incoming HTTP request to a PHP interpreter, let the interpreter do it’s thing, and finally collect the interpreter’s output and send it back as the HTTP response.
Ages ago, this was done using CGI. This involved spawning a PHP process for each incoming request. The overhead of spawning a process was not trivial. Modern day request rates and response expectations mean that this overhead is not tolerable, and CGI has mostly been consigned to the dustbin.
To avoid the process-spawning overhead, there are two obvious possibilities:
- host the interpreter in-proc within the web server
- have a daemon running a long-lived, reusable interpreter and have the web server talk to this daemon
The first approach is how mod_php works. mod_php is a loadable module for Apache, which contains a PHP interpreter (more than one actually) which is invoked to render the PHP. mod_php is also an Apache-only thing, and is not available for Nginx.
The second approach is how the FastCGI Process Manager (FPM) works. FPM can be used for both Apache and Nginx.
FPM
Apache and Nginx both have modules that can talk to FPM. They talk via a Unix
domain socket, typically at a path like /var/run/php/php5-fpm.sock
. The
incoming HTTP request is forwarded over this Unix domain socket to the FPM
daemon.
The FPM daemon manages a bunch of PHP processes. These are grouped into pools. The FPM can scale a pool up or down according to configured logic, which allows it to adapt to varying server load.
The daemon gets an idle PHP interpreter to process the incoming HTTP request, and write the response back to the web server over the Unix domain socket connection.
FPM Pool
The FPM pool is a bunch of (customized) PHP processes that are run an managed by
the FPM daemon. The pool has many configuration parameters, including the
scaling policy. These are typically set in a file like /etc/php5/fpm/pool.d/www.conf
where www
is the name of the pool.
Monitoring an FPM Pool
Among other parameters, you can set a “status URI”. This is set in the pool’s
configuration file as the parameter pm.status_path
, typically like:
At this URI, the FPM will serve up stats about health and performance of the pool. Note that the Apache or Nginx fronting the FPM should also have it’s configuration adjusted for the URI to be accessible.
Monitoring FPM with OpsDash
With OpsDash you can configure a “service” to collect these stats from the FPM pool, and graph it. In OpsDash SaaS, you can modify the agent configuration like so:
and in OpsDash self-hosted you can use the UI, to setup a new service. Here is how the FPM metrics are presented by default:
You can go from 0 to this in just a minute or two! OpsDash strives to save you the tedious work of setting up a useful dashboard.
This dashboard shows key metrics relevant to the PHP FPM instance’s health and performance:
- Requests Per Second: The rate of requests being processed.
- Pending Requests Per Second: The rate of requests pending to be processed.
- Process Count: The total number of active and idle FPM processes.
- Slow Requests Per Second: The rate of requests each second that exceed the slow limt (set by the configuration option “request_slowlog_timeout”). This metric may not be available in older versions of FPM.
You can of course, customize the dashboard, as well as set alerts for any metric. OpsDash can alert you via emails, Slack, HipChat, PagerDuty, OpsGenie, VictorOps or Webhooks when things begin to look wonky.
New Here?
OpsDash is a server monitoring, service monitoring, and database monitoring solution for monitoring Docker, MySQL, PostgreSQL, MongoDB, memcache, Redis, Apache, Nginx, Elasticsearch and more. It provides intelligent, customizable dashboards and rule-based alerting via email, HipChat, Slack, PagerDuty, OpsGenie, VictorOps and Webhooks. Send in your custom metrics with StatsD and Graphite interfaces built into each agent.