Hello all.
Derick (and other people) asked me to create an RFC for FPM describing what it is and why do we need it.
Quite.. ahem.. laconic version of such RFC can be found here: http://wiki.php.net/rfc/fpm
I'm open for your questions.
--
Wbr,
Antony Dovgal
http://pinba.org - realtime statistics for PHP
23.3.2010 18:42, Antony Dovgal wrote:
Hello all.
Derick (and other people) asked me to create an RFC for FPM describing what it is and why do we need it.
Quite.. ahem.. laconic version of such RFC can be found here: http://wiki.php.net/rfc/fpmI'm open for your questions.
Does it really need to be separate SAPI? I mean, just replace the old sapi/cgi
with it? Keep the name 'cgi' though. :)
--Jani
23.3.2010 18:42, Antony Dovgal wrote:
Hello all.
Derick (and other people) asked me to create an RFC for FPM describing what it is and why do we need it.
Quite.. ahem.. laconic version of such RFC can be found here: http://wiki.php.net/rfc/fpmI'm open for your questions.
Does it really need to be separate SAPI? I mean, just replace the old sapi/cgi
with it? Keep the name 'cgi' though. :)
I don't see any need to touch sapi/cgi at all.
Keeping both CGI and FastCGI in one SAPI leads to a nasty code mess with lots of
"if (fcgi_is_fastcgi()) {" as you can now see in cgi_main.c.
sapi/fpm and sapi/cgi now have quite different codebase as we've dropped some stuff
not pertinent to FastCGI (there might be some leftovers, I'll deal with them later).
--
Wbr,
Antony Dovgal
http://pinba.org - realtime statistics for PHP
sapi/fpm and sapi/cgi now have quite different codebase as we've dropped some stuff
not pertinent to FastCGI (there might be some leftovers, I'll deal with them later).
Not sure if it's best to say it here or just post to the wiki but it'd
be nice to add in:
- Jerome's put in some statistics functionality, which could be useful
in monitoring, etc. - might be nice to mention in the "features" [I
would include only the JSON output though] - The config file change, moving from the XML-based php-fpm.conf to
using php.ini (I think some work had started on this, but syntax was
under debate?) - this will make it easier to adopt I think and move
away from the feeling of "this was a separate party package we threw
in to PHP" - I think Jerome had began on changing this too
All the work both you and Jerome have done (and of course Andrei) is
-greatly- appreciated. There is a decent sized audience happy to see
this finally getting into PHP core.
If there is any help needed I did get an email from an organization
who said they could throw a bit of manpower towards it. I had been
meaning to email now that it's been announced that it won't be in
5.3.3 but it will be in 5.4 (or whatever the next version is) to try
to pool some attention and get people re-energized about contributing
to the project and such.
It'd be nice to be able to determine what planned features/changes
could be put in to make it on a 5.4 (that's what I'll call it) release
- I'm hoping statistics + config file change could make the grade.
Perhaps syslog support or some other useful stuff... there is a
wishlist of ideas already. I'll do whatever I can to help and we can
take it off the mailing list too. I'd love to be able to have a
decently tested FPM in 5.4 with some additional features/improvements - I'm sure when it comes out it'll still be marked as "experimental"
since it's the first version out there but I will run it on every
platform I can find and do anything I can to test it and throw a load
on it or anything to help. Everything but the C :P
At least it can be marked officially as "this is the first version in
core - use at own risk" but community members will be able to have a
feeling that it has been tested thoroughly ahead of time... a lot of
people are chomping at the bit to use a PHP core version.
2010/3/23 Michael Shadle mike503@gmail.com:
sapi/fpm and sapi/cgi now have quite different codebase as we've dropped some stuff
not pertinent to FastCGI (there might be some leftovers, I'll deal with them later).Not sure if it's best to say it here or just post to the wiki but it'd
be nice to add in:
- Jerome's put in some statistics functionality, which could be useful
in monitoring, etc. - might be nice to mention in the "features" [I
would include only the JSON output though]
It's already in the features (basic SAPI status info (similar to
Apache mod_status))
- The config file change, moving from the XML-based php-fpm.conf to
using php.ini (I think some work had started on this, but syntax was
under debate?) - this will make it easier to adopt I think and move
away from the feeling of "this was a separate party package we threw
in to PHP" - I think Jerome had began on changing this too
Yes I started a while ago but I stopped as we were not able to make a
choice ... so XML remains
All the work both you and Jerome have done (and of course Andrei) is
-greatly- appreciated. There is a decent sized audience happy to see
this finally getting into PHP core.If there is any help needed I did get an email from an organization
who said they could throw a bit of manpower towards it. I had been
meaning to email now that it's been announced that it won't be in
5.3.3 but it will be in 5.4 (or whatever the next version is) to try
to pool some attention and get people re-energized about contributing
to the project and such.It'd be nice to be able to determine what planned features/changes
could be put in to make it on a 5.4 (that's what I'll call it) release
- I'm hoping statistics + config file change could make the grade.
Perhaps syslog support or some other useful stuff... there is a
wishlist of ideas already. I'll do whatever I can to help and we can
take it off the mailing list too. I'd love to be able to have a
decently tested FPM in 5.4 with some additional features/improvements- I'm sure when it comes out it'll still be marked as "experimental"
since it's the first version out there but I will run it on every
platform I can find and do anything I can to test it and throw a load
on it or anything to help. Everything but the C :PAt least it can be marked officially as "this is the first version in
core - use at own risk" but community members will be able to have a
feeling that it has been tested thoroughly ahead of time... a lot of
people are chomping at the bit to use a PHP core version.
- Jerome's put in some statistics functionality, which could be useful
in monitoring, etc. - might be nice to mention in the "features" [I
would include only the JSON output though]
I mentioned it, albeit briefly:
- basic SAPI status info (similar to Apache mod_status)
- The config file change, moving from the XML-based php-fpm.conf to
using php.ini (I think some work had started on this, but syntax was
under debate?)
We've discussed this many times and I thought it's pretty clear that php.ini
syntax won't fit in this situation - the requirements are completely different.
- this will make it easier to adopt
I don't see how.
If there is any help needed I did get an email from an organization
who said they could throw a bit of manpower towards it.
They can do it any time - testing and reporting issues is a lot of work.
Patches are also appreciated, no need to wait for a 'go ahead' from anyone to do this.
--
Wbr,
Antony Dovgal
http://pinba.org - realtime statistics for PHP
Antony Dovgal wrote:
- Jerome's put in some statistics functionality, which could be useful
in monitoring, etc. - might be nice to mention in the "features" [I
would include only the JSON output though]I mentioned it, albeit briefly:
- basic SAPI status info (similar to Apache mod_status)
- The config file change, moving from the XML-based php-fpm.conf to
using php.ini (I think some work had started on this, but syntax was
under debate?)We've discussed this many times and I thought it's pretty clear that php.ini
syntax won't fit in this situation - the requirements are completely different.
Can you add this to the RFC so it doesn't keep getting asked,
and/or link to mail list discussions?
Also, is there an entry on http://wiki.php.net/rfc for your RFC?
Thanks,
Chris
- this will make it easier to adopt
I don't see how.
If there is any help needed I did get an email from an organization
who said they could throw a bit of manpower towards it.They can do it any time - testing and reporting issues is a lot of work.
Patches are also appreciated, no need to wait for a 'go ahead' from anyone to do this.
--
Email: christopher.jones@oracle.com
Tel: +1 650 506 8630
Blog: http://blogs.oracle.com/opal/
Free PHP Book: http://tinyurl.com/ugpomhome
I mentioned it, albeit briefly:
- basic SAPI status info (similar to Apache mod_status)
Missed it (oops)
We've discussed this many times and I thought it's pretty clear that php.ini
syntax won't fit in this situation - the requirements are completely different.
- this will make it easier to adopt
I don't see how.
When people see XML a lot of people have tried to use xpath and other
XML functionality - when really it's not a full-on XML document at
all. (People have asked on the mailing list) - also it's an external
configuration file with it's own syntax. It feels a bit foreign from
how people are used to configuring PHP. (I admit I do not have a
better alternative other than trying the php.ini approach which I
guess has been shot down now) - I am looking for the easiest path for
people to use this, that's all.
Perhaps some php.ini options for the pid file, config file, etc. So it
is not defined at compile time?
Also one other feature that would be neat is an "include"
functionality in the config file, which could help automated pool
definitions from scripts be created. A bit OT for this though.
They can do it any time - testing and reporting issues is a lot of work.
I have a lot of machines at my disposal and such and would love a way
to be able to put PHP-FPM through it's paces by running test scripts
or anything. I personally do not know how to create them nor what
portions are useful to test (tricky internals that might break under
certain situations, things that might have been changed when you moved
it from launchpad -> PHP SVN, etc.) - note that PHP-FPM for PHP 5.2.x
(the patch) seems to be solid as a rock, but 5.3 has had a handful of
issues or other complaints. So there is some fundamental differences
somewhere and those are the kind of things I'd like to figure out how
to get automated testing on...
Patches are also appreciated, no need to wait for a 'go ahead' from anyone to do this.
I just thought of a slightly more formal approach - perhaps a small
roadmap or prioritization of features - something small would be easy
to adopt in 5.4 without causing possible instability - but something
larger might be "don't bother with that right now - it is too big of a
change and won't make it in to 5.4 anyway. how about you tackle this
first?"
On Tue, Mar 23, 2010 at 12:43 PM, Antony Dovgal tony@daylessday.org
wrote:I mentioned it, albeit briefly:
- basic SAPI status info (similar to Apache mod_status)
Missed it (oops)
We've discussed this many times and I thought it's pretty clear that
php.ini
syntax won't fit in this situation - the requirements are completely
different.
- this will make it easier to adopt
I don't see how.
When people see XML a lot of people have tried to use xpath and other
XML functionality - when really it's not a full-on XML document at
all. (People have asked on the mailing list) - also it's an external
configuration file with it's own syntax. It feels a bit foreign from
how people are used to configuring PHP. (I admit I do not have a
better alternative other than trying the php.ini approach which I
guess has been shot down now) - I am looking for the easiest path for
people to use this, that's all.Perhaps some php.ini options for the pid file, config file, etc. So it
is not defined at compile time?Also one other feature that would be neat is an "include"
functionality in the config file, which could help automated pool
definitions from scripts be created. A bit OT for this though.They can do it any time - testing and reporting issues is a lot of work.
I have a lot of machines at my disposal and such and would love a way
to be able to put PHP-FPM through it's paces by running test scripts
or anything. I personally do not know how to create them nor what
portions are useful to test (tricky internals that might break under
certain situations, things that might have been changed when you moved
it from launchpad -> PHP SVN, etc.) - note that PHP-FPM for PHP 5.2.x
(the patch) seems to be solid as a rock, but 5.3 has had a handful of
issues or other complaints. So there is some fundamental differences
somewhere and those are the kind of things I'd like to figure out how
to get automated testing on...Patches are also appreciated, no need to wait for a 'go ahead' from
anyone to do this.I just thought of a slightly more formal approach - perhaps a small
roadmap or prioritization of features - something small would be easy
to adopt in 5.4 without causing possible instability - but something
larger might be "don't bother with that right now - it is too big of a
change and won't make it in to 5.4 anyway. how about you tackle this
first?"--
From a testing standpoint, if this becomes a new sapi, do we need to
introduce a new construct for dealing with tests that need to run on this
sapi only?
Example: --FPM-- which would be similar to the --CGI-- construct which
denotes that test as cgi sapi only.
Eric Lee Stewart
At 21:43 23/03/2010, Antony Dovgal wrote:
- The config file change, moving from the XML-based php-fpm.conf to
using php.ini (I think some work had started on this, but syntax was
under debate?)We've discussed this many times and I thought it's pretty clear that php.ini
syntax won't fit in this situation - the requirements are completely
different.
It's not clear at all. In fact I think it was very clear that using
php.ini syntax (together with sections if necessary) is very much an
option, and I think mostly everyone here leaned towards it.
- this will make it easier to adopt
I don't see how.
By using syntax we're using everywhere else for configuration,
instead of introducing a brand new one. .ini is also easier than XML
for mere mortals.
Zeev
2010/3/23 Zeev Suraski zeev@zend.com:
At 21:43 23/03/2010, Antony Dovgal wrote:
- The config file change, moving from the XML-based php-fpm.conf to
using php.ini (I think some work had started on this, but syntax was
under debate?)We've discussed this many times and I thought it's pretty clear that
php.ini
syntax won't fit in this situation - the requirements are completely
different.It's not clear at all. In fact I think it was very clear that using php.ini
syntax (together with sections if necessary) is very much an option, and I
think mostly everyone here leaned towards it.
- this will make it easier to adopt
I don't see how.
By using syntax we're using everywhere else for configuration, instead of
introducing a brand new one. .ini is also easier than XML for mere mortals.
In fact with INI syntax, there is a serious missing cause there is no
include system shiped with. And with FPM as there is potentialy many
"vhosts", it's necessary to have an include system to feet all system
administrator needs.
Zeev
2010/3/23 Jérôme Loyet jerome@loyet.net:
In fact with INI syntax, there is a serious missing cause there is no
include system shiped with. And with FPM as there is potentialy many
"vhosts", it's necessary to have an include system to feet all system
administrator needs.
That was something I brought up to internals a while back, was adding
in the ability for includes in the php.ini file. I can see many usage
models for this, from distributions to web hosting managers.
That would probably be pretty easy to implement I think and get in to 5.4 (?)
Also, either way, using the XML or php.ini approach, neither support
includes. However, two birds with one stone - make php.ini support
includes (look at mysql's config for example, it's an ini file with an
!include directive)
Hi!
That was something I brought up to internals a while back, was adding
in the ability for includes in the php.ini file. I can see many usage
models for this, from distributions to web hosting managers.
Actually, if you have extension parsing the .ini, nobody prevents you
from having:
include[]=another.ini
and have your extension interpret it as it wishes (i.e parse another
file). Only problem you have is if you want PHP to do it automatically
for you. So for FPM it shouldn't be a problem.
Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com
2010/3/23 Stanislav Malyshev stas@zend.com:
Actually, if you have extension parsing the .ini, nobody prevents you from
having:include[]=another.ini
and have your extension interpret it as it wishes (i.e parse another file).
Only problem you have is if you want PHP to do it automatically for you. So
for FPM it shouldn't be a problem.
I want PHP core to do it. Not only for FPM but for many other reasons. :)
MySQL does a !includedir thing...
* IMPORTANT: Additional settings that can override those from this file!
The files must end with '.cnf', otherwise they'll be ignored.
!includedir /etc/mysql/conf.d/
Hi!
I want PHP core to do it. Not only for FPM but for many other reasons. :)
MySQL does a !includedir thing...
Oh, well, that's another thing. Do an RFC then :)
Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com
At 22:44 23/03/2010, Jérôme Loyet wrote:
In fact with INI syntax, there is a serious missing cause there is no
include system shiped with. And with FPM as there is potentialy many
"vhosts", it's necessary to have an include system to feet all system
administrator needs.
We were talking about the syntax, not actually
using php.ini or PHP's INI subsystem. You can
use the ini parser to implement includes without a problem.
Zeev
It's not clear at all. In fact I think it was very clear that using
php.ini syntax (together with sections if necessary) is very much an
option, and I think mostly everyone here leaned towards it.
Just take a look at it:
http://svn.php.net/viewvc/php/php-src/branches/PHP_5_3_FPM/sapi/fpm/php-fpm.conf.in?revision=292487&view=markup
How do you propose to describe the same set of options using php.ini syntax?
Yes, simple things like "value=Yes/No" or "value=DIR" fit just fine into php.ini.
But how would decribe a set of pools each with its own set of options?
(taking into account that some of these options may override global options)
Last time I heard it was proposed to use copy/paste to add 'global' options to each pool =)
By using syntax we're using everywhere else for configuration,
instead of introducing a brand new one.
This is not a php.ini, this is a different config file for a different service.
You don't expect Apache to switch to php.ini syntax just because it's nice and familiar, do you?
.ini is also easier than XML for mere mortals.
Now I was never an XML fan myself, but I think THIS particular XML config file
is even easier to read and understand than php.ini.
--
Wbr,
Antony Dovgal
http://pinba.org - realtime statistics for PHP
Now I was never an XML fan myself, but I think THIS particular XML config file
is even easier to read and understand than php.ini.
There was one other suggestion / something Andrei wanted to do (at
least he mentioned to me) and that was change the config file to be
nginx style, a bit more structured and cleaner than XML.
It won't solve anything here necessarily and introduces -another-
config file syntax but perhaps a cleaner interim one and the parser
supports includes and such already. Just throwing that out there.
Ideally I'd love to see a way for a single php.ini to drive everything
and an include-driven directory for specific things (per pool for fpm,
per-server for server specific information) but one generic php.ini I
could distribute to all the servers I maintain, for example.
At 22:55 23/03/2010, Antony Dovgal wrote:
It's not clear at all. In fact I think it was very clear that using
php.ini syntax (together with sections if necessary) is very much an
option, and I think mostly everyone here leaned towards it.Just take a look at it:
http://svn.php.net/viewvc/php/php-src/branches/PHP_5_3_FPM/sapi/fpm/php-fpm.conf.in?revision=292487&view=markuphttp://svn.php.net/viewvc/php/php-src/branches/PHP_5_3_FPM/sapi/fpm/php-fpm.conf.in?revision=292487&view=markupHow do you propose to describe the same set of options using php.ini syntax?
Yes, simple things like "value=Yes/No" or "value=DIR" fit just fine
into php.ini.
But how would decribe a set of pools each with its own set of options?
(taking into account that some of these options may override global options)
option...
anotheroption...
[pool1]
option...
anotheroption...
[pool2]
option...
anotheroption...
By using syntax we're using everywhere else for configuration,
instead of introducing a brand new one.This is not a php.ini, this is a different config file for a
different service.
You don't expect Apache to switch to php.ini syntax just because
it's nice and familiar, do you?
It's a config for a part of PHP, not Apache. I do expect it to look
like everything else I configure in PHP. There appear to be good
reasons to separate it from php.ini - but not for having it use
different syntax.
.ini is also easier than XML for mere mortals.
Now I was never an XML fan myself, but I think THIS particular XML config file
is even easier to read and understand than php.ini.
We can agree to disagree on that - it's subjective - but objectively
.ini is PHP's way of setting configuration, XML is not.
Zeev
How do you propose to describe the same set of options using php.ini syntax?
Yes, simple things like "value=Yes/No" or "value=DIR" fit just fine
into php.ini.
But how would decribe a set of pools each with its own set of options?
(taking into account that some of these options may override global options)option...
anotheroption...[pool1]
option...
anotheroption...[pool2]
option...
anotheroption...
Okay, here is XML based config quickly converted to php.ini-style syntax:
[fpm.flobals]
pid_file = /usr/local/var/run/php-fpm.pid
error_log = /usr/local/var/log/php-fpm.log
log_level = notice
emergency_restart_threshold = 10
emergency_restart_interval = 1m
process_control_timeout = 5s
daemonize = yes
[fpm.workers]
[default]
listen_address = 127.0.0.1:9000
listen_options =
backlog = -1
owner = nobody
group = nobody
mode = 0666
[php_defines]
sendmail_path = /usr/sbin/sendmail -t -i
display_errors = 0
error_log = /var/log/php-error.log
log_errors = true
[----- Uhm, no way to mark the end of the section ------]
user = nobody
group = nobody
[pm]
style = static
max_children = 50
status = /status
ping = /ping
pong = pong
[dynamic]
start_servers = 20
min_spare_servers = 5
max_spare_servers = 35
[----- Uhm, no way to mark the end of the section ------]
request_terminate_timeout = 0s
request_slowlog_timeout = 0s
slowlog = /usr/local/var/log/php-fpm.log.slow
rlimit_files = 1024
rlimit_core = 0
chroot =
chdir =
catch_workers_output = yes
max_requests = 500
allowed_clients = 127.0.0.1
[environment]
HOSTNAME = $HOSTNAME
PATH = /usr/local/bin:/usr/bin:/bin
TMP = /tmp
TMPDIR = /tmp
TEMP = /tmp
OSTYPE = $OSTYPE
MACHTYPE = $MACHTYPE
MALLOC_CHECK_ = 2
[----- Uhm, no way to mark the end of the section ------]
[----- Uhm, no way to mark the end of the section ------]
[----- Uhm, no way to mark the end of the section ------]
[----- Uhm, no way to mark the end of the section ------]
[----- Uhm, no way to mark the end of the section ------]
I won't discuss how it looks to me, but there is only one problem: it doesn't work.
That's because php.ini doesn't support nested sections and without them it turns into a real mess.
--
Wbr,
Antony Dovgal
http://pinba.org - realtime statistics for PHP
Okay, here is XML based config quickly converted to php.ini-style syntax:
[fpm.flobals]
pid_file = /usr/local/var/run/php-fpm.pid
error_log = /usr/local/var/log/php-fpm.log
log_level = notice
emergency_restart_threshold = 10
emergency_restart_interval = 1m
process_control_timeout = 5s
daemonize = yes[fpm.workers]
[default]
listen_address = 127.0.0.1:9000
listen_options =
backlog = -1
owner = nobody
group = nobody
mode = 0666
[php_defines]
sendmail_path = /usr/sbin/sendmail -t -i
display_errors = 0
error_log = /var/log/php-error.log
log_errors = true
isn't this where the new array syntax could work? note: I think arrays
in ini files are scary, but nonetheless they are there.
fpm.worker('workername').listen_address = 127.0.0.1:9000
etc
At 23:58 23/03/2010, Antony Dovgal wrote:
Okay, here is XML based config quickly converted to php.ini-style syntax:
Here's mine - a bit more representative of how .ini files look
instead of trying to convert a nested XML file:
[globals]
pid_file = /usr/local/var/run/php-fpm.pid
error_log = /usr/local/var/log/php-fpm.log
log_level = notice
emergency_restart_threshold = 10
emergency_restart_interval = 1m
process_control_timeout = 5s
daemonize = yes
listen_address = 127.0.0.1:9000
listen_options =
backlog = -1
owner = nobody
group = nobody
mode = 0666
php_defines.sendmail_path = /usr/sbin/sendmail -t -i
php_defines.display_errors = 0
php_defines.error_log = /var/log/php-error.log
php_defines.log_errors = true
user = nobody
group = nobody
[default]
pm.style = static
pm.max_children = 50
pm.status = /status
pm.ping = /ping
pm.pong = pong
dynamic.start_servers = 20
dynamic.min_spare_servers = 5
dynamic.max_spare_servers = 35
request_terminate_timeout = 0s
request_slowlog_timeout = 0s
slowlog = /usr/local/var/log/php-fpm.log.slow
rlimit_files = 1024
rlimit_core = 0
chroot =
chdir =
catch_workers_output = yes
max_requests = 500
allowed_clients = 127.0.0.1
environment.HOSTNAME = $HOSTNAME
environment.PATH = /usr/local/bin:/usr/bin:/bin
environment.TMP = /tmp
environment.TMPDIR = /tmp
environment.TEMP = /tmp
envrionment.OSTYPE = $OSTYPE
environment.MACHTYPE = $MACHTYPE
environment.MALLOC_CHECK_ = 2
At 23:58 23/03/2010, Antony Dovgal wrote:
Okay, here is XML based config quickly converted to php.ini-style syntax:
Here's mine - a bit more representative of how .ini files look
instead of trying to convert a nested XML file:
I'm sure you understand that nesting makes things much more easier to read.
fpm.workers.<pool name ASCII only and no spaces>.pm.dynamic.start_servers is not my preferred syntax.
And yes, this is how it should look like since you're implying that FPM config
should be a part of php.ini (otherwise I don't see how these two different files are related at all).
--
Wbr,
Antony Dovgal
http://pinba.org - realtime statistics for PHP
At 00:25 24/03/2010, Antony Dovgal wrote:
At 23:58 23/03/2010, Antony Dovgal wrote:
Okay, here is XML based config quickly converted to php.ini-style syntax:
Here's mine - a bit more representative of how .ini files look
instead of trying to convert a nested XML file:I'm sure you understand that nesting makes things much more easier to read.
Only if it's really necessary, which doesn't appear to be the case here.
fpm.workers.<pool name ASCII only and no spaces>.pm.dynamic.start_servers is not my preferred syntax.
I find the .ini version (the one I submitted) way, way easier to read
- it's designed for humans and requires no parsing. I don't see why
we need to add fpm.workers.poolname.pm.dynamic, where fpm.workers is
obvious, and poolname is in the section name. You're left with
pm.dynamic - which is fine.
And yes, this is how it should look like since you're implying that FPM config
should be a part of php.ini (otherwise I don't see how these two
different files are related at all).
I'm not implying it, in fact I'm downright saying the opposite. It
should be in its own fpm.ini file, using .ini syntax. It shouldn't
use PHP's INI subsystem since it's irrelevant to it, and we may want
to implement special handling for certain directive names (e.g.
includes, should we decide to implement them).
All along I was talking about the syntax, not php.ini itself.
Zeev
Hi!
I'm sure you understand that nesting makes things much more easier to read.
fpm.workers.<pool name ASCII only and no spaces>.pm.dynamic.start_servers is not my preferred syntax.
This is actually highly debatable. Nesting does not allow you an easy
way to know where each value belongs to - you'd have to climb up the
tree and hope you didn't skip some branch by chance. Of course, it is
much more verbose, but you don't really need that many levels of
hierarchy. If you give up on literally translating xml, I'm sure you'll
notice that start_servers can live on it's own without being prefixed,
etc. So you'd have one level for FPM in general, one for specific
worker, one for category and one for actual option:
fpm.myworker.server.start_servers = 20
fpm.myworker.php_defines.memory_limit = 64M
etc. It's not that bad.
As for spaces in pool names - come on, you're not going to write a novel
there. No programming language allows spaces in identifiers and we
manage to live with it :)
And yes, this is how it should look like since you're implying that FPM config
should be a part of php.ini (otherwise I don't see how these two different files are related at all).
It shouldn't be part of php.ini, but it'd be nice if it was part of php
config system.
Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com
fpm.myworker.server.start_servers = 20
fpm.myworker.php_defines.memory_limit = 64Metc. It's not that bad.
"Not that bad" doesn't sound very convincing.
I'd personally prefer something better than that.
As for spaces in pool names - come on, you're not going to write a novel
there. No programming language allows spaces in identifiers and we
manage to live with it :)
No, I'm not going to write a novel.
But I'm sure many users would like to use domain name as a pool name.
As you might guess, "fpm.www.blah.com.php_defines"; is not going to work, too.
It shouldn't be part of php.ini, but it'd be nice if it was part of php
config system.
It has nothing to do with PHP config system, it's a different thing and it has it's own configuration.
--
Wbr,
Antony Dovgal
http://pinba.org - realtime statistics for PHP
How do you propose to describe the same set of options using php.ini syntax?
Yes, simple things like "value=Yes/No" or "value=DIR" fit just fine
into php.ini.
But how would decribe a set of pools each with its own set of options?
(taking into account that some of these options may override global options)option...
anotheroption...[pool1]
option...
anotheroption...[pool2]
option...
anotheroption...Okay, here is XML based config quickly converted to php.ini-style syntax:
<skipped…>
I won't discuss how it looks to me, but there is only one problem: it doesn't work.
That's because php.ini doesn't support nested sections and without them it turns into a real mess.
looks almost like YAML ;)
Now I was never an XML fan myself, but I think THIS particular XML config file
is even easier to read and understand than php.ini.
Actually, I agree with Antony on this point. The existing XML config
file is pretty easy to read. I didn't implement it myself, but during
a (brief period) as maintainer for the FPM code, I saw absolutely no
need to change it. Even if you are unfamiliar with xml, the file is
well commented. But heh, I happened to be one of those people who
never really understood php ini files. So maybe im a bit biased. But I
never ever had even a single person email me saying they couldnt
understand the xml config file. If anything, it felt like quite the
reverse situation. People kept emailing me, telling me all this stuff
about what it did, that I was unaware of.
Whats missing in my view is clear documentation to explain each of the
configuration options. Which may be a good thing for either the FPM
unix man page, or the parallel (seperate) php online documentation.
--
Wbr,
Antony Dovgalhttp://pinba.org - realtime statistics for PHP
hi Tony,
Does it really need to be separate SAPI? I mean, just replace the old sapi/cgi
with it? Keep the name 'cgi' though. :)I don't see any need to touch sapi/cgi at all.
Keeping both CGI and FastCGI in one SAPI leads to a nasty code mess with lots of
"if (fcgi_is_fastcgi()) {" as you can now see in cgi_main.c.
Not sure to follow, are you suggesting to consider FPM as the
sapi/cgi's fastcgi replacement? As Jani is suggesting.
sapi/fpm and sapi/cgi now have quite different codebase as we've dropped some stuff
not pertinent to FastCGI (there might be some leftovers, I'll deal with them later).
By the way, how portable is it? I don't think it has been tested on
windows (some of the key features are not necessary with IIS/FCGI as
they do it already but could be for other web servers).
I would suggest to keep it as a separate sapi for now, or forever if it works.
Cheers,
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
2010/3/23 Pierre Joye pierre.php@gmail.com:
hi Tony,
Does it really need to be separate SAPI? I mean, just replace the old sapi/cgi
with it? Keep the name 'cgi' though. :)I don't see any need to touch sapi/cgi at all.
Keeping both CGI and FastCGI in one SAPI leads to a nasty code mess with lots of
"if (fcgi_is_fastcgi()) {" as you can now see in cgi_main.c.Not sure to follow, are you suggesting to consider FPM as the
sapi/cgi's fastcgi replacement? As Jani is suggesting.sapi/fpm and sapi/cgi now have quite different codebase as we've dropped some stuff
not pertinent to FastCGI (there might be some leftovers, I'll deal with them later).By the way, how portable is it? I don't think it has been tested on
windows (some of the key features are not necessary with IIS/FCGI as
they do it already but could be for other web servers).
As far as I know, It's not been tested on windows. It depends on
libevent which is available for windows, so porting fpm to windows
should not be a big deal (technicaly I mean, it'll maybe take some
time). I'm not a windows dev specialist, I'm maybe missing a point
somewhere.
I would suggest to keep it as a separate sapi for now, or forever if it works.
Cheers,
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
hi Tony,
Does it really need to be separate SAPI? I mean, just replace the old sapi/cgi
with it? Keep the name 'cgi' though. :)I don't see any need to touch sapi/cgi at all.
Keeping both CGI and FastCGI in one SAPI leads to a nasty code mess with lots of
"if (fcgi_is_fastcgi()) {" as you can now see in cgi_main.c.Not sure to follow, are you suggesting to consider FPM as the
sapi/cgi's fastcgi replacement? As Jani is suggesting.
No, I suggest to keep sapi/cgi in place and add sapi/fpm as another sapi module.
This will also ensure that well-tested and mature sapi/cgi will keep being as it is.
By the way, how portable is it?
Well, I've already seen a complaint about ARM support missing.
But you're asking about Windows, I guess.
I don't think it has been tested on
windows (some of the key features are not necessary with IIS/FCGI as
they do it already but could be for other web servers).
No, certainly no Windows testing were done that is known to me.
I'm pretty sure it doesn't even compile there.
And to be honest I doubt there is any need to spend time on it.
I would suggest to keep it as a separate sapi for now, or forever if it works.
I'd prefer it to stay separate sapi.
--
Wbr,
Antony Dovgal
http://pinba.org - realtime statistics for PHP
Derick (and other people) asked me to create an RFC for FPM describing
what it is and why do we need it. Quite.. ahem.. laconic version of
such RFC can be found here: http://wiki.php.net/rfc/fpmI'm open for your questions.
Can you merge it to trunk please? I saw no nay's for including the
functionality. The config format can be sorted out later if necessary.
regards,
Derick
--
http://derickrethans.nl | http://xdebug.org
Like Xdebug? Consider a donation: http://xdebug.org/donate.php
twitter: @derickr and @xdebug