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
- 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
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
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
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
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_fpmJust 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
2009/12/7 Antony Dovgal tony@daylessday.org:
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
Hi!
Couple of other notes here:
-
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. -
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
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
Hi!
Couple of other notes here:
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.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
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
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
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
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)
Le 8 décembre 2009 01:04, Michael Shadle mike503@gmail.com 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 = nogroupetc?
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)
hi!
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_fpmJust 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,
Pierre
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.
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_fpmBuilding 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 runphp-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 Dovgalhttp://pinba.org - realtime statistics for PHP
"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
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?
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.
- 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
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
Sent from my iPhone
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
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
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
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
2009/12/7 Michael Shadle mike503@gmail.com:
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 usageAt 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.
hi,
- 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
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)
hi,
- 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
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)
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
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?)
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.
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_fpmBuilding 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 runphp-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 Dovgalhttp://pinba.org - realtime statistics for PHP