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:

pm.status_path = /fpm_www_status

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:

service "my-fpm-www" { type = "php-fpm" url = "http://127.0.0.1/path/to/fpm_www_status" }

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.

: The rate of requests being processed. Pending Requests Per Second : The rate of requests pending to be processed.

: The rate of requests pending to be processed. Process Count : The total number of active and idle FPM processes.

: 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.