• Categories
  • Recent
  • Tags
  • Popular
  • Users
  • Search
  • Register
  • Login
Netgate Discussion Forum
  • Categories
  • Recent
  • Tags
  • Popular
  • Users
  • Search
  • Register
  • Login

Php-cli & php-fpm

Scheduled Pinned Locked Moved Development
3 Posts 2 Posters 3.0k Views
Loading More Posts
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • X
    Xon
    last edited by Sep 24, 2013, 3:50 PM Sep 24, 2013, 3:47 PM

    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.

    1 Reply Last reply Reply Quote 0
    • E
      eri--
      last edited by Sep 30, 2013, 12:46 PM

      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.

      1 Reply Last reply Reply Quote 0
      • X
        Xon
        last edited by Sep 30, 2013, 2:33 PM

        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.

        1 Reply Last reply Reply Quote 0
        3 out of 3
        • First post
          3/3
          Last post
        Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.
          This community forum collects and processes your personal information.
          consent.not_received