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.