PHP Fast(er)CGI Process Manager

Make my client faster than it actually is with `fastcgi_finish_request()`.

PHP FPM provides method that drives regular process execution flow into something unusual.
Let’s see what happens in typical PHP FPM setup?

There is incoming web request from the client that hits web server (eg. nginx), this request is forwarded to PHP FPM server.

PHP spawns new process that executes your code, which in the end returns some data in form of response, that through web server reaches client.

By using `fastcgi_finish_request()` you can change slightly lifetime of your php process and make it appearing faster (shorter) to the client.

Aforementioned function call is telling to the web server that whole response from PHP FPM was sent and connection to the client can be closed (after sending all remain data in web server buffers).

Depending on your code and usage of external resources you can leverage this method call to divide request processing time into part that maters to the client and not. Clients don’t care if you record activity in form of logs, collect metrics in monitoring tools or send requests into other services. They just want to get some data in return and that’s it.

This means execution flow can look like this:

What are the downsides of such usage?

After you call `fastcgi_finish_request()` you have no chance to notify client about dany failure. This means all issues, error has to be written somewhere else than standard output.
In real life, production setup you may be using load balancers, resource scaling based on web server metrics (handled requests) and because PHP FPM processing time is not equal to web server processing time anymore this may lead to inaccurate scaling results. In such scenario driving metrics should be coming from PHP FPM and not web server.

It is easy to get lazy and try to do too much in post request time. Try to be sane and don’t do anything that fits perfectly into asynchronous processing (like sending emails, generating PDF files).

At the same time this is quick win for improving client response time and staring refactoring synchronous operations as asynchronous.

Another idea is to introduce in memory events dispatching between subdomains in big, monolith applications. This will create “realtime” feel in change propagation. However, it is important to track time spent on active response, and post response processing time to not go too far and keep sanity. Don’t spend 10% of time on building client response and 90% on other things…