PHP-FPM

Thoughts and experiences with PHP-FPM, be aware of the limits. Not everything is working on hosters that provide php.

The site PHP.net shows a wunderful collection of functionality. It started out as a kind of preprocessor for a private home page. Now it is hypertext preprocessor. There are lot of extensions and it is possible to dynamically load libraries for additional functionality. However, web-hosters only offer a limited amount of functionality. And those limits renders certain applications impossible.

Dynamic web content #

Early web was much like the ancient gopher internet, only that the number of protocols was reduced to 1. A simple text-based request-response exchange protocol created the base. At first, one could retrieve simple hypertext, a derivative of SGML with XML being a cousin. That hypertext contained references to other content on the web. In the beginning, content could only be retrieved, like gopher did.

Then CGI kicked in, allowing scripts to process user input and to display results based on that. CGI-scripts were often written in perl, each request resulting in one process invocation.

Fast-CGI allowed one invocation to process several requests.

Tomcat made it possible to process several requests in parallel within one framework and let the container handle all common base functions. Jboss extends this functionality to a cluster.

Webhosters #

It is their business to host content on their servers. Static stuff can be served within the web-server, while active content needs to be confined. As the web-server runs under its own account, all cgi programs run under the same account. This meant that any evil user could read content that was accessible under that account. Even chroot did not changed much. Fast-CGI changed that, now the web-server related the requests to a different process, which could run under a different account.

Webhosters offer limited functionality. Some dynamic content is desired, like running a website builder like Wordpress. However, for security reason, not everything is allowed that might be possible. Moreover, webhosters want to reduce the load on their systems, hence they employ caching.

Caching of static web content seems to be a strange thing. An efficient web server already serves content in a way that caching cannot improve. Dynamic content on the other hand should not be cached.

For a website builder, just some functionality and power needs to be released/available.

What PHP could do #

In theory, PHP could handle websockets and hence offer bidirectional communication. Even though websockets are based on HTTP during handshake, it is not possible to upgrade a Fast-CGI connection, as PHP needs to create the listenin websocket.

PHP can also function as an upstream web server, hence only loading the code once. The cli version once had threads, which could have offered functionality similar to Tomcat, although not the performance. One request could notify another thread which then could have sent Server-Sent-Events (SSE) in a stream. SSE are an alternative to long-polls.

There are PHP extensions that allow communication between threads, then one listener could wait for a signal from a publisher.

PHP-FPM and its limits #

FPM stands for Fast-CGI process manager, which coordinates the dealing with requests. The system starts a master process that opens a receiving socket (unix or ip). Each request is delegated to a worker process from a pool, which the FPM manages. Those workers can run under a different account or in a different chroot environment. Webhosters might reduce the maximal number of workers to a ridiculous low number.

In PHP-FPM php runs as a single threaded process, dealing with one request at a time. There are multi-threaded versions possible – however, one should not count on this. Even though, the Zend engine caches the op-code, all required code needs to be loaded for each request. This means that there is a limited throughput for a given number of workers.

Horrific discovery regarding my webhoster #

First of all, my hoster does not allow continuous streaming which makes SSE impossible. There is a varnish web-cache, an apache that buffers and then Fast-CGI. Long-polls that wait for a notification and then return a reponse are technically possible. However, each PHP-FPM worker process can only handle one request at a time. And my hoster limits that number to 4. Hence, each long-poll handling would block other requests - hence not possible.

The sad realization is that my hoster is only useful for short lived requests. An application like a webchat is therefore not possible.