Php-cli & php-fpm



  • Per ermal's comment here, regarding improving php-cli's performance the suggestion was to implement something akin to php-fpm.

    While I'm a programmer, my typical role is as an application's developer. So, I haven't had much experiance building php and haven't built the pfsense enviroment before. But I don't really see that as a major hurdle.

    My first thoughts where;

    • Modify eligiable scripts to use #!/usr/local/bin/php-wrapper rather than #!/usr/local/bin/php

    • php-wrapper would take the invoked filename, and fetch it from a loopback-based lighttpd vhost and output any results to standard output. Not sure about exit codes.

    • The lighttpd vhost would check the remote IP, use loopback. (custom port?).

    This would serve as a proof-of-concept that everything works as expected after being moved form php-cli into long running php processes. It saves having to configure Yet Another php daemon watcher (as lighttpd does this).

    Issues off the top of my head;

    • It probably on makes sense for some php-cli tasks to be converted.

    • I don't the implication that the system background tasks would share the same worker pool as the webserver, and would likely split that into a seperate fcgi instance.

    • I'ld need to determine how deep the nesting of php-cli application goes, as this requires that many worker processes to prevent deadlock/worker pool exhaustion.

    • first past would have php-wrapper as a shell script, rewriting to a native application looks quite simple.

    • Talking to a php-fpm socket directly would remove the dependancy on lighttpd, but introduce the requirement to write a fastcgi client.

    I've mocked together a first pass at php-wrapper and started poking at how lighty-webConfigurator.conf is stuctured so I can alter the update process. I don't see every php-cli instance being replaced, because ultimately there would need to be a bootstrap phase for configuring without it and a recovery process.

    I'm also intending to base this on the 2.1 code base for the moment.



  • You are over complicating it.

    The idea is to use php-fpm with threads module and write a listener for messages.
    This way you do not have to write a client for fcgi but just post a message to a queue of sorts.

    Most of the scripts just call a existing php function and that is the idea.



  • You can't use php-fpm like that, as there is no way to post fcgi requests to the php-fpm management process without a fcgi client. And the php-fpm worker processes aren't going todo much if the management process isn't sending them jobs.

    And writing a php server app which pushing request handling into threads is really a bad idea considering I wouldn't trust the php-interpreter to be properly threadsafe never mind any extensions that may need to be used.


Log in to reply