FAQ
Hello all.

I'm glad to announce that we now have FPM SAPI available for testing in a separate SVN branch.

You can check out its sources using the following command:
svn co http://svn.php.net/repository/php/php-src/branches/PHP_5_3_FPM php_5_3_fpm

Building FPM is as easy as `./configure --enable-fpm && make install`.
After that you need to adjust the default config file (installed into $prefix/etc)
and run `php-fpm`.


For those who don't know what FPM is: FPM (FastCGI Process Manager) is an alternative
PHP FastCGI implementation with some additional features useful for heavy-loaded sites.
These features include:
- advanced process management with graceful stop/start;
- ability to start workers with different uid/gid/chroot/environment and different php.ini (replaces safe_mode);
- stdout & stderr logging;
- emergency restart in case of accidental opcode cache destruction;
- accelerated upload support;
- "slowlog";
- fastcgi_finish_request() - special function to finish request & flush all data while
continuing to do something time-consuming (video converting, stats processing etc.);
and some more.

You are welcome to test the code and report any issues to me (since it's not fully official,
we don't have a category @ bugs.php.net yet).

--
Wbr,
Antony Dovgal
---
http://pinba.org - realtime statistics for PHP

Search Discussions

  • Jordi Boggiano at Dec 4, 2009 at 1:42 pm

    On 04.12.2009 13:53, Antony Dovgal wrote:
    - advanced process management with graceful stop/start;
    - ability to start workers with different uid/gid/chroot/environment and different php.ini (replaces safe_mode);
    - stdout & stderr logging;
    - emergency restart in case of accidental opcode cache destruction;
    - accelerated upload support;
    - "slowlog";
    - fastcgi_finish_request() - special function to finish request & flush all data while
    continuing to do something time-consuming (video converting, stats processing etc.);
    and some more.
    Most awesome features, seems like it allows you to easily skip all the
    *suexec stuff too to build a multi-user hosting environment. Thanks a
    lot to you and whoever was involved in this, I hope I can manage to try
    this soon.

    Cheers,
    Jordi
  • Johannes Schlüter at Dec 4, 2009 at 1:59 pm

    On Fri, 2009-12-04 at 15:53 +0300, Antony Dovgal wrote:
    Hello all.

    I'm glad to announce that we now have FPM SAPI available for testing in a separate SVN branch.

    You can check out its sources using the following command:
    svn co http://svn.php.net/repository/php/php-src/branches/PHP_5_3_FPM php_5_3_fpm
    How big would be the impact in regards to BC and stuff for merging it
    back in 5_3? If i read the svn log correct it's just a SAPI ... so
    adding it might be low risk as it only affects people using it.

    Is it related to the CGI SAPI codewise? If yes: would there be plans to
    merge it in some way or would we have to fix bugs in CGI, FPM and
    probably CLI which all have the same roots?

    johannes
  • Antony Dovgal at Dec 4, 2009 at 2:07 pm

    On 04.12.2009 16:58, Johannes Schlüter wrote:
    How big would be the impact in regards to BC and stuff for merging it
    back in 5_3? If i read the svn log correct it's just a SAPI ... so
    adding it might be low risk as it only affects people using it.
    That's right, it's a separate SAPI, it doesn't affect anything beyond sapi/fpm in any way.
    Is it related to the CGI SAPI codewise?
    Yes, it uses modified versions of cgi_main.c and fastcgi.c/.h.
    If yes: would there be plans to
    merge it in some way or would we have to fix bugs in CGI, FPM and
    probably CLI which all have the same roots?
    I'm planning to remove some more unused/unnecessary code from fpm_main.c.
    I guess this will somewhat reduce the amount of porting between the "copy" and original file.

    --
    Wbr,
    Antony Dovgal
    ---
    http://pinba.org - realtime statistics for PHP
  • Stanislav Malyshev at Dec 4, 2009 at 9:18 pm
    Hi!
    You can check out its sources using the following command:
    svn co http://svn.php.net/repository/php/php-src/branches/PHP_5_3_FPM php_5_3_fpm
    Just curious - any plans for win32 support?
    --
    Stanislav Malyshev, Zend Software Architect
    stas@zend.com http://www.zend.com/
    (408)253-8829 MSN: stas@zend.com
  • Antony Dovgal at Dec 7, 2009 at 9:21 am

    On 05.12.2009 00:18, Stanislav Malyshev wrote:
    Hi!
    You can check out its sources using the following command:
    svn co http://svn.php.net/repository/php/php-src/branches/PHP_5_3_FPM php_5_3_fpm
    Just curious - any plans for win32 support?
    If you want to work on it - sure, no problem.
    But you know me, I have neither knowledge nor desire to work on it myself.
    Also a heavy loaded server on Windows is something out of this world to me.

    --
    Wbr,
    Antony Dovgal
    ---
    http://pinba.org - realtime statistics for PHP
  • Jérôme Loyet at Dec 7, 2009 at 9:31 am

    2009/12/7 Antony Dovgal <tony@daylessday.org>:
    On 05.12.2009 00:18, Stanislav Malyshev wrote:
    Hi!
    You can check out its sources using the following command:
    svn co http://svn.php.net/repository/php/php-src/branches/PHP_5_3_FPM php_5_3_fpm
    Hi tony,

    I've been working on php-fpm. If I want to submit patches, what is the
    best way to do it ?

    ++ jerome
  • Antony Dovgal at Dec 7, 2009 at 9:37 am

    On 07.12.2009 12:30, Jérôme Loyet wrote:
    You can check out its sources using the following command:
    svn co http://svn.php.net/repository/php/php-src/branches/PHP_5_3_FPM php_5_3_fpm
    Hi tony,

    I've been working on php-fpm. If I want to submit patches, what is the
    best way to do it ?
    Send them to internals@ and CC me, this way they won't be lost for sure.

    --
    Wbr,
    Antony Dovgal
    ---
    http://pinba.org - realtime statistics for PHP
  • Stanislav Malyshev at Dec 7, 2009 at 6:49 pm
    Hi!

    Couple of other notes here:

    1. I understand this SAPI uses its own XML config format. While it is
    not unheard of for SAPIs to integrate into external servers and thus
    have diferent config ways, this one is self contained - so I wonder if
    it would be possible to make it configured by .ini? We have .ini parser,
    people know what .ini format is, etc.

    2. Do we need <value name="php_defines"> if we already have user ini files?
    --
    Stanislav Malyshev, Zend Software Architect
    stas@zend.com http://www.zend.com/
    (408)253-8829 MSN: stas@zend.com
  • Michael Shadle at Dec 7, 2009 at 7:11 pm
    For #2 it might no longer be needed that might be up for debate. It's
    nice to be able to override a single option. But 5.3 with it's
    htaccess/htscanner behavior might work good enough for most things
    (but PHP_INI_SYSTEM might be still nice to override one offs instead
    of having to point to a totally separate ini file) unless you say that
    there is a global ini file with defaults and the per-pool override is
    just overrides for that.

    As for #1 we are working on changing the config file syntax and the
    idea was to make it use nginx style. I don't think it will fit in ini
    file format as it needs arrays or some sort of n+1 group structure
    support/nested options.

    IIRC array support did just get inplemented in 5.3 did it not? That -
    may- be an option then. Then fpm could actually share php.ini itself.

    I guess it depends on if the ini support php has will work well with
    nested groupings.

    Sent from my iPhone
    On Dec 7, 2009, at 10:49 AM, Stanislav Malyshev wrote:

    Hi!

    Couple of other notes here:

    1. I understand this SAPI uses its own XML config format. While it
    is not unheard of for SAPIs to integrate into external servers and
    thus have diferent config ways, this one is self contained - so I
    wonder if it would be possible to make it configured by .ini? We
    have .ini parser, people know what .ini format is, etc.

    2. Do we need <value name="php_defines"> if we already have user ini
    files?
    --
    Stanislav Malyshev, Zend Software Architect
    stas@zend.com http://www.zend.com/
    (408)253-8829 MSN: stas@zend.com

    --
    PHP Internals - PHP Runtime Development Mailing List
    To unsubscribe, visit: http://www.php.net/unsub.php
  • Stanislav Malyshev at Dec 7, 2009 at 7:58 pm
    Hi!
    As for #1 we are working on changing the config file syntax and the idea
    was to make it use nginx style. I don't think it will fit in ini file
    format as it needs arrays or some sort of n+1 group structure
    support/nested options.
    Nesting can be done by name, and .ini can do arrays. See here:
    http://php.net/parse_ini_file
    and also here:
    http://framework.zend.com/manual/en/zend.config.adapters.ini.html
    for how you can do stuff with .ini's :)
    IIRC array support did just get inplemented in 5.3 did it not? That
    -may- be an option then. Then fpm could actually share php.ini itself.
    [] was working in 5.2 too. 5.3 can do indexes.
    --
    Stanislav Malyshev, Zend Software Architect
    stas@zend.com http://www.zend.com/
    (408)253-8829 MSN: stas@zend.com
  • Jérôme Loyet at Dec 7, 2009 at 8:16 pm

    2009/12/7 Stanislav Malyshev <stas@zend.com>:
    Hi!
    As for #1 we are working on changing the config file syntax and the idea
    was to make it use nginx style. I don't think it will fit in ini file format
    as it needs arrays or some sort of n+1 group structure support/nested
    options.
    Nesting can be done by name, and .ini can do arrays. See here:
    http://php.net/parse_ini_file
    and also here:
    http://framework.zend.com/manual/en/zend.config.adapters.ini.html
    for how you can do stuff with .ini's :)
    IIRC array support did just get inplemented in 5.3 did it not? That -may-
    be an option then. Then fpm could actually share php.ini itself.
    Yes INI is natively handled in PHP (and adding the missing include
    function is easy) and I already did it. But the syntax is not that
    good for php-fpm, try to configure apache, tomcat or nginx with INI
    syntax ... it's a pain in the ass as xml is. Despite all that, php-fpm
    aim is to run as a standalone daemon which has never been the aim of
    any sapi before (maybe I'm wrong) and therefore INI syntax has never
    been used in a such context.

    Here is en example of nginx syntax and then INI ... I my mind there is
    no comparaison.

    pid /var/run/php-fpm.pid;
    error_log /var/log/php-fpm.log;
    log_level notice;
    emergency_restart_threshold 10;
    emergency_restart_interval 1m;
    process_control_timeout 5s;
    daemonize no;
    worker {
    name default;
    listen {
    address tcp:127.0.0.1:9000;
    backlog -1;
    owner nobody;
    group nogroup;
    mode 0666;
    }
    php_define short_open_tag=On;

    user nobody;
    group nogroup;
    static {
    max_children 5;
    }
    dynamic {
    max_children 20;
    StartServers 5;
    MinSpareServers 5;
    MaxSpareServers 15;
    }

    request_terminate_timeout 0s;
    request_slowlog_timeout 0s;
    slowlog /var/log/php-fpm.log.slow;
    rlimit_files 1024;
    rlimit_core 0;
    chroot /usr/local/nginx/html;
    chdir /;
    catch_workers_output yes;
    max_requests 500;
    allowed_clients 127.0.0.1;
    env HOSTNAME=$HOSTNAME;
    env PATH=/usr/local/bin:/usr/bin:/bin;
    }

    And the same with ini
    pid = /var/run/php-fpm.pid
    error_log = /var/log/php-fpm.log
    log_level = notice
    emergency_restart_threshold = 10
    emergency_restart_interval = 1m
    process_control_timeout = 5s
    daemonize = no

    worker.name= default;
    worker.listen.address = tcp:127.0.0.1:9000
    worker.listen.backlog = -1
    worker.listen.owner = nobody
    worker.listen.group = nogroup
    worker.listen.mode = 0666
    worker.php_defineshort_open_tag = On

    worker.user = nobody
    worker.group = nogroup
    worker.static.max_children = 5
    worker.dynamic.max_children = 20
    worker.dynamic.start_servers = 5
    worker.dynamic.min_spare_servers = 5
    worker.dynamic.max_spare_servers = 15
    worker.request_terminate_timeout = 0s
    worker.request_slowlog_timeout = 0s
    worker.slowlog = /var/log/php-fpm.log.slow
    worker.rlimit_files = 1024
    worker.rlimit_core = 0
    worker.chroot = /usr/local/nginx/html
    worker.chdir = /
    worker.catch_workers_output = yes
    worker.max_requests = 5000
    worker.allowed_clients = 127.0.0.1
    worker.env.HOSTNAME = $HOSTNAME
    worker.env.PATH = /usr/local/bin:/usr/bin:/bin


    [] was working in 5.2 too. 5.3 can do indexes.
    --
    Stanislav Malyshev, Zend Software Architect
    stas@zend.com   http://www.zend.com/
    (408)253-8829   MSN: stas@zend.com

    --
    PHP Internals - PHP Runtime Development Mailing List
    To unsubscribe, visit: http://www.php.net/unsub.php
  • Stanislav Malyshev at Dec 7, 2009 at 8:48 pm
    Hi!
    worker.name= default;
    worker.listen.address = tcp:127.0.0.1:9000
    worker.listen.backlog = -1
    worker.listen.owner = nobody
    worker.listen.group = nogroup
    worker.listen.mode = 0666
    worker.php_defineshort_open_tag = On
    You could also do it as:
    [WORKER=default]
    listen.address = tcp:127.0.0.1:9000
    ...etc...
    env["HOSTNAME"]=$HOSTNAME
    ...etc...
    --
    Stanislav Malyshev, Zend Software Architect
    stas@zend.com http://www.zend.com/
    (408)253-8829 MSN: stas@zend.com
  • Michael Shadle at Dec 8, 2009 at 12:04 am
    2009/12/7 Jérôme Loyet <jerome@loyet.net>:

    so you're saying each worker just has a worker.name prefixed

    worker.name = pool1
    worker.user = nobody
    worker.group = nogroup
    worker.static.max_children = 5
    worker.dynamic.max_children = 20
    worker.dynamic.start_servers = 5
    worker.dynamic.min_spare_servers = 5
    worker.dynamic.max_spare_servers = 15
    ...etc...

    worker.name = pool2
    worker.user = nobody
    worker.group = nogroup
    worker.static.max_children = 5
    worker.dynamic.max_children = 20
    worker.dynamic.start_servers = 5
    worker.dynamic.min_spare_servers = 5
    worker.dynamic.max_spare_servers = 15
    ...etc...

    not something like

    worker('pool2').user = nobody
    worker('pool2').group = nogroup

    etc?

    i guess i'm fine with it either was as long as it is easy for end
    users. also it would be nice to programatically generate it and be
    able to include it (would require php.ini to have include support.
    mysql does this with the !include directive, IIRC)
  • Jérôme Loyet at Dec 8, 2009 at 12:10 am

    Le 8 décembre 2009 01:04, Michael Shadle a écrit :
    2009/12/7 Jérôme Loyet <jerome@loyet.net>:

    so you're saying each worker just has a worker.name prefixed

    worker.name = pool1
    worker.user = nobody
    worker.group = nogroup
    worker.static.max_children = 5
    worker.dynamic.max_children = 20
    worker.dynamic.start_servers = 5
    worker.dynamic.min_spare_servers = 5
    worker.dynamic.max_spare_servers = 15
    ...etc...

    worker.name = pool2
    worker.user = nobody
    worker.group = nogroup
    worker.static.max_children = 5
    worker.dynamic.max_children = 20
    worker.dynamic.start_servers = 5
    worker.dynamic.min_spare_servers = 5
    worker.dynamic.max_spare_servers = 15
    ...etc...

    not something like

    worker('pool2').user = nobody
    worker('pool2').group = nogroup

    etc?
    Yes it could be this way ... but you do repeat the pattern ('pool2')
    for each entry. There is about 30 lines for each workers ... no
    imagine having a multiuser environment with 30 customers ... you have
    900 times a useless repeated pattern ... gnurf
    i guess i'm fine with it either was as long as it is easy for end
    users.
    I think we all agree here :) cf my previous comment.
    also it would be nice to programatically generate it
    What do you mean by programatically generate it, in which goal ?
    and be
    able to include it (would require php.ini to have include support.
    mysql does this with the !include directive, IIRC)
  • Christopher Jones at Dec 8, 2009 at 12:23 am

    Jérôme Loyet wrote:
    Yes it could be this way ... but you do repeat the pattern ('pool2')
    for each entry. There is about 30 lines for each workers ... no
    imagine having a multiuser environment with 30 customers ... you have
    900 times a useless repeated pattern ... gnurf
    If there are deficiencies in php.ini syntax, then propose an
    enhancement and/or work around them in FPM. Having two syntaxes in
    use will be more confusing in the long term.

    Chris
  • Jérôme Loyet at Dec 8, 2009 at 12:49 am
    Le 8 décembre 2009 01:21, Christopher Jones
    <christopher.jones@oracle.com> a écrit :

    Jérôme Loyet wrote:
    Yes it could be this way ... but you do repeat the pattern ('pool2')
    for each entry. There is about 30 lines for each workers ... no
    imagine having a multiuser environment with 30 customers ... you have
    900 times a useless repeated pattern ... gnurf
    If there are deficiencies in php.ini syntax, then propose an
    enhancement and/or work around them in FPM.  Having two syntaxes in
    use will be more confusing in the long term.
    It could be something like:

    ; general conf
    ; [/] optional section
    pid=/var/run/php-fpm.pid
    log_level=notice

    ;pool1
    [/worker]
    name=pool1
    [/worker/listen]
    address=127.0.0.1:9001
    [/worker/pm]
    style=dynamic
    max_children=32
    [/worker/env]
    HOSTNAME=$HOSTNAME
    [/worker/php_define]
    short_open_tags = On

    ;pool2
    [/worker]
    name=pool2
    [/worker/listen]
    address=127.0.0.1:9002
    ...

    In this case conf file is very flat. I don't know if identation is
    available with INI (hope so). As there is no closing section all
    entries have to be ordered correctly (this is not easy for the end
    user).

    There is a workarround with adding accolades (or similar):
    [/worker{]
    [/worker/listen{]
    [}]
    [}]
    But in this case we have almost the same syntax as ngninx (with
    brackets arround sections and = signs to separate keys and values).

    At the begening of the reflexion the choice of nginx has been made
    because most of php-fpm users will use nginx or lighthttp (apache as
    its well known module) and some developpement have been made for nginx
    at the first place.

    As the question is "which is the best syntax for end users" I want to
    ask this question "Who are the end users of php-fpm and what are their
    willing ?".
  • Pierre Joye at Dec 7, 2009 at 9:40 am
    hi!
    On Fri, Dec 4, 2009 at 10:18 PM, Stanislav Malyshev wrote:
    Hi!
    You can check out its sources using the following command:
    svn co http://svn.php.net/repository/php/php-src/branches/PHP_5_3_FPM
    php_5_3_fpm
    Just curious - any plans for win32 support?
    I remember some discussions about it but I did not follow the recent
    developments. We can take a look at a possible port once it is "ready"
    (when Antony is done with the cleanup).

    Cheers,
  • Michael Shadle at Dec 5, 2009 at 12:26 am
    Antony - thank you so much! This is quite a surprise though, I didn't
    know there were plans for this... I was talking to gwynne on IRC about
    the best way to get this going.

    I suppose it being a separate SAPI works, but I had also thought:

    "What if it was just a modification to the FCGI SAPI, and the FPM
    management features, config file parsing, all that were in a
    standalone daemon. That allows for a lot of changes and such to be
    done in the daemon portion without having to align it with PHP
    releases"

    I don't think a lot has to be done really to the internals once the
    portions you've listed before were adopted. Only a few IPC, socket or
    command line options to start/stop from an external daemon would need
    to be involved, and communication to allow for adaptive process
    spawning...

    We've been wanting to change the configuration file syntax already and
    the majority of "wishlist" items we've wanted to add mainly fall under
    the manager daemon... I am just scared that it may take a while for
    those to be released if it has to fall under PHP's release cycle (not
    to mention do other SAPIs have their own configuration files and such?
    Seems like an awful lot of 'special needs' is now bundled in to a SAPI
    inside of PHP core)

    Either way though - this is a win. I was unaware this was even
    happening. We've been having discussions on the php-fpm mailing list
    about this and a little bit of internal battling on it too (mainly
    100% php core vs. only the portions needed in php core, etc.)

    This is awesome though. Hopefully we can get things moving faster. If
    anyone is interested in the ideas we have to make things easier to use
    and enhance some functionality *please* don't hesitate to email me off
    list. I have a feeling the majority of items aren't actually that
    difficult.

    On Fri, Dec 4, 2009 at 4:53 AM, Antony Dovgal wrote:
    Hello all.

    I'm glad to announce that we now have FPM SAPI available for testing in a separate SVN branch.

    You can check out its sources using the following command:
    svn co http://svn.php.net/repository/php/php-src/branches/PHP_5_3_FPM php_5_3_fpm

    Building FPM is as easy as `./configure --enable-fpm && make install`.
    After that you need to adjust the default config file (installed into $prefix/etc)
    and run `php-fpm`.


    For those who don't know what FPM is: FPM (FastCGI Process Manager) is an alternative
    PHP FastCGI implementation with some additional features useful for heavy-loaded sites.
    These features include:
    - advanced process management with graceful stop/start;
    - ability to start workers with different uid/gid/chroot/environment and different php.ini (replaces safe_mode);
    - stdout & stderr logging;
    - emergency restart in case of accidental opcode cache destruction;
    - accelerated upload support;
    - "slowlog";
    - fastcgi_finish_request() - special function to finish request & flush all data while
    continuing to do something time-consuming (video converting, stats processing etc.);
    and some more.

    You are welcome to test the code and report any issues to me (since it's not fully official,
    we don't have a category @ bugs.php.net yet).

    --
    Wbr,
    Antony Dovgal
    ---
    http://pinba.org - realtime statistics for PHP

    --
    PHP Internals - PHP Runtime Development Mailing List
    To unsubscribe, visit: http://www.php.net/unsub.php
  • Antony Dovgal at Dec 7, 2009 at 9:26 am

    On 05.12.2009 03:25, Michael Shadle wrote:
    "What if it was just a modification to the FCGI SAPI, and the FPM
    management features, config file parsing, all that were in a
    standalone daemon. That allows for a lot of changes and such to be
    done in the daemon portion without having to align it with PHP
    releases"
    That's the thing I want to avoid, actually.
    Moving something out of PHP just because you're afraid of its release cycles
    means you make it harder to maintain, not easier.

    --
    Wbr,
    Antony Dovgal
    ---
    http://pinba.org - realtime statistics for PHP
  • Michael Shadle at Dec 7, 2009 at 10:01 am

    On Mon, Dec 7, 2009 at 1:25 AM, Antony Dovgal wrote:

    That's the thing I want to avoid, actually.
    Moving something out of PHP just because you're afraid of its release cycles
    means you make it harder to maintain, not easier.
    Even if it is just the management component of it?

    Any of the PHP internals will still stay inside of PHP. It will only
    be the daemon portion that tells the new SAPI how to behave (spawn
    more under this pool, kill this child, do that?) etc?
  • Michael Shadle at Dec 7, 2009 at 11:35 am

    On Mon, Dec 7, 2009 at 2:01 AM, Michael Shadle wrote:
    On Mon, Dec 7, 2009 at 1:25 AM, Antony Dovgal wrote:

    That's the thing I want to avoid, actually.
    Moving something out of PHP just because you're afraid of its release cycles
    means you make it harder to maintain, not easier.
    Even if it is just the management component of it?

    Any of the PHP internals will still stay inside of PHP. It will only
    be the daemon portion that tells the new SAPI how to behave (spawn
    more under this pool, kill this child, do that?) etc?
    Or, perhaps move it into PECL at least?

    There are still many things TBD in PHP-FPM, one of them was a
    discussion about possibly changing the model to make it more
    accommodating for shared hosting providers.

    Other features grokked from the wishlist/would be logged as "feature
    requests" when I had setup the bug tracker:
    - Adaptive process support (the major thing lacking)
    - CPU affinity/load balancing
    - Config file syntax change
    - Syslog support
    - Per-pool php.ini file (should be easy)
    - See if the normal libevent or libev could handle all the needs and
    not a patched copy anymore (or get with the libevent team)
    - Metrics/reporting, possibly like postfix's anvil reports out, or a
    way to query the SAPI to get an idea of usage

    At the moment unless these changes are ready for commitment into a PHP
    beta build they won't get out until the next one, and so on... at
    least with PECL there is a clear delineation from core.

    Anyway, as acting manager for the project I really would like to be
    able to figure out the future - what we should be doing on the side
    (obviously trying to work on code and submit it when ready) but do we
    still maintain the documentation, or will it migrate to php.net then?
    Since the SAPI includes the config file, now all of a sudden that
    becomes thrown under the PHP core umbrella for documentation, and the
    existing XML configuration (and desired nginx style configuration)
    both do not line up with the INI style configuration that PHP users
    are used to.

    This might be one of the main reasons why I think having the
    daemon/management portion be split out. Otherwise, if it is part of
    core, then core has to have pages with documentation for all of this
    as well, bug tracking for it, etc. Quite possibly, if split apart, a
    better management daemon or tool would be developed as well, as the
    API would be in place to manage the FPM SAPI'ed PHP processes from an
    external manager. (Heck, do I see control panel integration points?
    cpanel/plesk/etc. could now define PHP process quotas per user for
    example?)

    Just spitballing here. You're ultimately the master of this domain. I
    also don't want to spam the list. I'm more than happy to pro/con this
    offline with you. Or have you tell me flat out what I should be
    changing on the community side of things. "Keep your own svn, but keep
    it in sync with our branch. Once a feature is complete and assumed bug
    free, then send the patch to us" or "Use php.net for the bugtracker
    now, there is no need for an external website anymore either.
    Documentation will also be hosted on php.net as well" ... etc.
  • Reinis Rozitis at Dec 7, 2009 at 1:30 pm

    - See if the normal libevent or libev could handle all the needs and
    not a patched copy anymore (or get with the libevent team)
    Isn't this is allready done since 0.6.x fpm? Afaik php-fpm needs external libevent on system now.
    - Adaptive process support (the major thing lacking)
    Somewhat done with the 'apache-like' spawning mechanism?

    rr
  • Jérôme Loyet at Dec 7, 2009 at 1:57 pm

    2009/12/7 Reinis Rozitis <r@roze.lv>:
    - See if the normal libevent or libev could handle all the needs and
    not a patched copy anymore (or get with the libevent team)
    Isn't this is allready done since 0.6.x fpm? Afaik php-fpm needs external
    libevent on system now.
    there is no more patch libevent, it's dependent of official libevent.
    It's all ok.
    - Adaptive process support (the major thing lacking)
    Somewhat done with the 'apache-like' spawning mechanism?
    As far as I know nohting has been done about adaptive process support
    or 'apache-like' spawning mechanism. It's been present in conf file
    without being supported.
    rr



    --
    PHP Internals - PHP Runtime Development Mailing List
    To unsubscribe, visit: http://www.php.net/unsub.php
  • Michael Shadle at Dec 7, 2009 at 5:47 pm
    Sent from my iPhone
    On Dec 7, 2009, at 5:57 AM, Jérôme Loyet wrote:

    2009/12/7 Reinis Rozitis <r@roze.lv>:
    - See if the normal libevent or libev could handle all the needs and
    not a patched copy anymore (or get with the libevent team)
    Isn't this is allready done since 0.6.x fpm? Afaik php-fpm needs
    external
    libevent on system now.
    there is no more patch libevent, it's dependent of official libevent.
    It's all ok.
    Shows how much I know. I haven't used 0.6.x yet because all my build
    scripts worked flawlessly with the patch.

    - Adaptive process support (the major thing lacking)
    Somewhat done with the 'apache-like' spawning mechanism?
    As far as I know nohting has been done about adaptive process support
    or 'apache-like' spawning mechanism. It's been present in conf file
    without being supported.
    Correct. Biggest lacking feature.
    rr



    --
    PHP Internals - PHP Runtime Development Mailing List
    To unsubscribe, visit: http://www.php.net/unsub.php
    --
    PHP Internals - PHP Runtime Development Mailing List
    To unsubscribe, visit: http://www.php.net/unsub.php
  • Reinis Rozitis at Dec 7, 2009 at 6:26 pm
    Correct. Biggest lacking feature.
    While this maybe a bit out of topic, but just out of curiosity why do you think that adaptive spawning is any good (trying to run
    more processes in given time period than started) - "stepping" back to how apache operates with its prefork mechanism (iirc there
    are even people from php-dev community which suggested running apache with start/maxservers identical so there is always constant
    number of childs (for php processing) to avoid unwanted/unexpected resource consumption?

    There should be reasons why it was also dropped from the other external process manager lighty/spawn-fcgi and never planned in
    webservers like nginx ..


    I would rather want to see one day php (master process) return FCGI_OVERLOADED for the webserver/application to decide what to do
    next.

    rr
  • Michael Shadle at Dec 7, 2009 at 7:13 pm
    The problem with running a static amount of processes is trying to
    figure out the right number. Also it is not elastic in any fashion.
    Shared hosts would love the elasticity as it will allow sites to flex
    up and down as needed without giving each individual user more
    processes than they really need

    A global max amount of processes or memory consumption metric might be
    useful to throttle the entire daemon from spawning new children.

    Sent from my iPhone
    On Dec 7, 2009, at 10:26 AM, "Reinis Rozitis" wrote:

    Correct. Biggest lacking feature.
    While this maybe a bit out of topic, but just out of curiosity why
    do you think that adaptive spawning is any good (trying to run more
    processes in given time period than started) - "stepping" back to
    how apache operates with its prefork mechanism (iirc there are even
    people from php-dev community which suggested running apache with
    start/maxservers identical so there is always constant number of
    childs (for php processing) to avoid unwanted/unexpected resource
    consumption?

    There should be reasons why it was also dropped from the other
    external process manager lighty/spawn-fcgi and never planned in
    webservers like nginx ..


    I would rather want to see one day php (master process) return
    FCGI_OVERLOADED for the webserver/application to decide what to do
    next.

    rr




    --
    PHP Internals - PHP Runtime Development Mailing List
    To unsubscribe, visit: http://www.php.net/unsub.php
  • Jérôme Loyet at Dec 7, 2009 at 2:41 pm

    2009/12/7 Michael Shadle <mike503@gmail.com>:
    On Mon, Dec 7, 2009 at 2:01 AM, Michael Shadle wrote:
    On Mon, Dec 7, 2009 at 1:25 AM, Antony Dovgal wrote:

    That's the thing I want to avoid, actually.
    Moving something out of PHP just because you're afraid of its release cycles
    means you make it harder to maintain, not easier.
    Even if it is just the management component of it?

    Any of the PHP internals will still stay inside of PHP. It will only
    be the daemon portion that tells the new SAPI how to behave (spawn
    more under this pool, kill this child, do that?) etc?
    Before integration of php-fpm in the official php tree I agreed with
    you about separating daemon stuff out of php tree and include only
    necessary functions (communication about spawning, chroot, ...) in
    php-fastcgi (cgi sapi).

    But as it's been totaly included as an independant sapi, I don't see
    any benefit to split. The fpm sapi would be only a patch version of
    the cgi sapi in order to work exclusively with an external software.
    This is illogical to me. And as tony has worked on this integration it
    would be a waste of time to change this.

    I hear you concerns about frequency of releases. Why don't follow
    patch against official release on the php-fpm website or something
    like that ? We have some thinking to do to find a solution that
    pleases everyone.
    Or, perhaps move it into PECL at least?
    What PECL can help here ? Is PECL just a compiled packages library for PHP ?
    There are still many things TBD in PHP-FPM, one of them was a
    discussion about possibly changing the model to make it more
    accommodating for shared hosting providers.

    Other features grokked from the wishlist/would be logged as "feature
    requests" when I had setup the bug tracker:
    - Adaptive process support (the major thing lacking)
    - CPU affinity/load balancing
    - Config file syntax change
    - Syslog support
    - Per-pool php.ini file (should be easy)
    - See if the normal libevent or libev could handle all the needs and
    not a patched copy anymore (or get with the libevent team)
    - Metrics/reporting, possibly like postfix's anvil reports out, or a
    way to query the SAPI to get an idea of usage

    At the moment unless these changes are ready for commitment into a PHP
    beta build they won't get out until the next one, and so on... at
    least with PECL there is a clear delineation from core.

    Anyway, as acting manager for the project I really would like to be
    able to figure out the future - what we should be doing on the side
    (obviously trying to work on code and submit it when ready) but do we
    still maintain the documentation, or will it migrate to php.net then?
    Since the SAPI includes the config file, now all of a sudden that
    becomes thrown under the PHP core umbrella for documentation, and the
    existing XML configuration (and desired nginx style configuration)
    both do not line up with the INI style configuration that PHP users
    are used to.

    This might be one of the main reasons why I think having the
    daemon/management portion be split out. Otherwise, if it is part of
    core, then core has to have pages with documentation for all of this
    as well, bug tracking for it, etc. Quite possibly, if split apart, a
    better management daemon or tool would be developed as well, as the
    API would be in place to manage the FPM SAPI'ed PHP processes from an
    external manager. (Heck, do I see control panel integration points?
    cpanel/plesk/etc. could now define PHP process quotas per user for
    example?)

    Just spitballing here. You're ultimately the master of this domain. I
    also don't want to spam the list. I'm more than happy to pro/con this
    offline with you. Or have you tell me flat out what I should be
    changing on the community side of things. "Keep your own svn, but keep
    it in sync with our branch. Once a feature is complete and assumed bug
    free, then send the patch to us" or "Use php.net for the bugtracker
    now, there is no need for an external website anymore either.
    Documentation will also be hosted on php.net as well" ... etc.

    --
    PHP Internals - PHP Runtime Development Mailing List
    To unsubscribe, visit: http://www.php.net/unsub.php
  • Pierre Joye at Dec 8, 2009 at 10:48 am
    hi,
    On Mon, Dec 7, 2009 at 12:35 PM, Michael Shadle wrote:
    - Per-pool php.ini file (should be easy)
    Why would you need that given that we have host, path or .user.ini
    support? Which has to be backported to FPM as far as I know.

    Cheers,
  • Michael Shadle at Dec 8, 2009 at 10:50 am
    you're probably right. i mainly am only thinking of PHP_INI_SYSTEM and
    things the user can't or shouldn't change themselves in .user.ini type
    files or with things like htscanner (pre 5.3)

    On Tue, Dec 8, 2009 at 2:47 AM, Pierre Joye wrote:
    hi,
    On Mon, Dec 7, 2009 at 12:35 PM, Michael Shadle wrote:
    - Per-pool php.ini file (should be easy)
    Why would you need that given that we have host, path or .user.ini
    support? Which has to be backported to FPM as far as I know.

    Cheers,
    --
    Pierre

    http://blog.thepimp.net | http://www.libgd.org
  • Michael Shadle at Dec 8, 2009 at 11:04 am
    On Tue, Dec 8, 2009 at 2:47 AM, Pierre Joye wrote:
    Why would you need that given that we have host, path or .user.ini
    support? Which has to be backported to FPM as far as I know.
    you're probably right. i mainly am only thinking of PHP_INI_SYSTEM and
    things the user can't or shouldn't change themselves in .user.ini type
    files or with things like htscanner (pre 5.3)
    Actually, I retract that.

    Unless there is a "Pool" identifier added:

    Host can be different for the same pool
    Path can be different for the same pool
    .user.ini's don't work for *every* ini option.

    Or, instead of per-pool .ini files, then just have per-pool ini
    overloads, using the previous example, something like:

    worker.name= default;
    worker.listen.address = tcp:127.0.0.1:9000
    worker.listen.backlog = -1
    worker.listen.owner = nobody
    worker.listen.group = nogroup
    worker.listen.mode = 0666
    worker.php_defineshort_open_tag = On
    worker.ini.error_reporting = E_ALL (yes this is not a big deal to
    change on another level, but just using it as an example)
  • Stanislav Malyshev at Dec 8, 2009 at 6:57 pm
    Hi!
    Unless there is a "Pool" identifier added:

    Host can be different for the same pool
    Path can be different for the same pool
    .user.ini's don't work for *every* ini option.
    How real would be the case of 2 hosts in the same pool having same
    configs, but the same hosts in different pool having different configs?

    In general, it's not a problem having another configuration mechanism like:

    worker.ini.error_reporting = E_ALL

    or even better strip worker. prefix - it looks like everything in worker
    section is for worker, so just have something like:

    [worker:blah]
    ini.error_reporting=E_ALL

    --
    Stanislav Malyshev, Zend Software Architect
    stas@zend.com http://www.zend.com/
    (408)253-8829 MSN: stas@zend.com
  • Michael Shadle at Dec 8, 2009 at 9:10 pm

    On Tue, Dec 8, 2009 at 10:57 AM, Stanislav Malyshev wrote:

    How real would be the case of 2 hosts in the same pool having same configs,
    but the same hosts in different pool having different configs?
    I never though about that but I can tell you I use all my websites
    under the same pool. I partition my pools by uid/gid. So each client
    has their own pool. Many hosts. Typically same path prefix, but that's
    not a safe bet. Pool is somewhat agnostic to the host/path.
    or even better strip worker. prefix - it looks like everything in worker
    section is for worker, so just have something like:

    [worker:blah]
    ini.error_reporting=E_ALL
    well to match the existing syntax you'd want [WORKER=blah] - let's not
    introduce too many syntaxes and such. I already think that the [HOST=]
    and [PATH=] can conflict (never did ask what happens if both get
    matched, foo.com and /htdocs/foo.com, but they have different
    parameters. Is it the last one in order in the config file?)
  • Michael Shadle at Dec 5, 2009 at 12:40 am
    what version of PHP-FPM code is this based off of? the latest 0.6.x at
    launchpad or one of the older patches?

    we have had reports of some issues with php 5.3.x and php-fpm 0.6.x.
    Andrei had changed the code from being a patch to being a standalone
    daemon that builds against vanilla php sources for the "new" 0.6.x
    generation. Just want to know when in the timeline you pulled the code
    from so we can ask people to test the bugs they reported against it to
    see if it's still a bug.
    On Fri, Dec 4, 2009 at 4:53 AM, Antony Dovgal wrote:
    Hello all.

    I'm glad to announce that we now have FPM SAPI available for testing in a separate SVN branch.

    You can check out its sources using the following command:
    svn co http://svn.php.net/repository/php/php-src/branches/PHP_5_3_FPM php_5_3_fpm

    Building FPM is as easy as `./configure --enable-fpm && make install`.
    After that you need to adjust the default config file (installed into $prefix/etc)
    and run `php-fpm`.


    For those who don't know what FPM is: FPM (FastCGI Process Manager) is an alternative
    PHP FastCGI implementation with some additional features useful for heavy-loaded sites.
    These features include:
    - advanced process management with graceful stop/start;
    - ability to start workers with different uid/gid/chroot/environment and different php.ini (replaces safe_mode);
    - stdout & stderr logging;
    - emergency restart in case of accidental opcode cache destruction;
    - accelerated upload support;
    - "slowlog";
    - fastcgi_finish_request() - special function to finish request & flush all data while
    continuing to do something time-consuming (video converting, stats processing etc.);
    and some more.

    You are welcome to test the code and report any issues to me (since it's not fully official,
    we don't have a category @ bugs.php.net yet).

    --
    Wbr,
    Antony Dovgal
    ---
    http://pinba.org - realtime statistics for PHP

    --
    PHP Internals - PHP Runtime Development Mailing List
    To unsubscribe, visit: http://www.php.net/unsub.php

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupphp-internals @
categoriesphp
postedDec 4, '09 at 12:54p
activeDec 8, '09 at 9:10p
posts34
users9
websitephp.net

People

Translate

site design / logo © 2022 Grokbase