Here’s an interesting solution for a poor man’s asynchronous queue using PHP-FPM:
PHP-FPM already acts as a queue for Nginx/Apache FastCGI clients. While your web-request is running you can just send another FastCGI request to the same PHP-FPM socket asynchronously and non-blocking. This request is immediately executed in another php-fpm process in parallel and you could wait for it to complete or just fire and forget.
Given the experimental nature of this approach, you probably won’t be running this in production. Â And with many developers switching to the built-in PHP web server for the local development, this doesn’t work for those environments other.
But it makes me think what else can be used as a queuing mechanism. Â After all, there are plenty of systems that rely on this already – email servers, printer spoolers, web and proxy servers, and probably more.
It certainly is a novel approach to using php-fpm, but I’d not consider it overly experimental. It involves the old and tried socket API on the client side and php-fpm on the server side, which is also well tested. Sure, the controlling PHP code is new and thus experimental but no less experimental than new code that uses ZeroMQ or something else, i.e. new code that needs testing like any new code.
Using the built-in PHP webserver you are not doing yourself any favor. It has its own funny behavior, e.g. treating paths with a dot always as static filenames and then trying to serve that file, even if it doesn’t exist. So you have to expect that production and dev behavior may differ. Also, on the topic of worker queues: you’ll never be able to achieve that in dev if you use the built-in webserver because it is single threaded. I gave up on the built-in webserver some time ago. It was created for the PHP test suite. While it may work well there, I just can’t recommend it for general development.
I agree. I’m just having it here more for an “idea” approach, rather than a real implementation. This idea can inspire some other implementations. :)