# FPM RFC - Thread: https://externals.io/message/47486 - Original archive: https://news-web.php.net/php.internals/47486 - Started by Antony Dovgal on 2010-03-23T16:42:23+00:00 - Messages: 53 - Page 1 of 3: messages 1 to 25 (25 per page, add `?page=N` to the URL) - Next page: https://externals.io/message/47486.md?page=2 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #47486 — Antony Dovgal — 2010-03-23T16:42:23+00:00 URL: https://externals.io/message/47486#47486 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 --- ## #47491 — Jani Taskinen — 2010-03-23T17:15:26+00:00 URL: https://externals.io/message/47486#47491 · In reply to: #47486 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/fpm > > I'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 --- ## #47493 — Antony Dovgal — 2010-03-23T17:25:25+00:00 URL: https://externals.io/message/47486#47493 · In reply to: #47491 > 23.3.2010 18:42, Antony Dovgal wrote: > > […] > > 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 --- ## #47499 — Michael Shadle — 2010-03-23T19:26:47+00:00 URL: https://externals.io/message/47486#47499 · In reply to: #47493 > 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. --- ## #47500 — jerome@loyet.net — 2010-03-23T19:36:36+00:00 URL: https://externals.io/message/47486#47500 · In reply to: #47499 2010/3/23 Michael Shadle : > > > > […] > > 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 :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. --- ## #47501 — Pierre Joye — 2010-03-23T19:37:45+00:00 URL: https://externals.io/message/47486#47501 · In reply to: #47493 hi Tony, > > […] > > 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 --- ## #47502 — Antony Dovgal — 2010-03-23T19:43:14+00:00 URL: https://externals.io/message/47486#47502 · In reply to: #47499 > - 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 --- ## #47503 — jerome@loyet.net — 2010-03-23T19:47:42+00:00 URL: https://externals.io/message/47486#47503 · In reply to: #47501 2010/3/23 Pierre Joye : > hi Tony, > > > > > […] > > Not sure to follow, are you suggesting to consider FPM as the > sapi/cgi's fastcgi replacement? As Jani is suggesting. > > > […] > > 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 --- ## #47504 — Antony Dovgal — 2010-03-23T19:49:43+00:00 URL: https://externals.io/message/47486#47504 · In reply to: #47501 > hi Tony, > > > > > […] > > 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 --- ## #47505 — Christopher Jones — 2010-03-23T19:51:45+00:00 URL: https://externals.io/message/47486#47505 · In reply to: #47502 Antony Dovgal wrote: > > > […] > > I mentioned it, albeit briefly: > * basic SAPI status info (similar to Apache mod_status) > > > […] > > 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 > > > […] > > I don't see how. > > > […] > > 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 --- ## #47506 — Michael Shadle — 2010-03-23T20:09:41+00:00 URL: https://externals.io/message/47486#47506 · In reply to: #47502 > 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. > > > […] > > 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?" --- ## #47507 — Eric Stewart — 2010-03-23T20:29:00+00:00 URL: https://externals.io/message/47486#47507 · In reply to: #47506 > On Tue, Mar 23, 2010 at 12:43 PM, Antony Dovgal > wrote: > > > […] > > Missed it (oops) > > > […] > php.ini > > […] > different. > > […] > > 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. > > > […] > > 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... > > > […] > 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 --- ## #47508 — Zeev Suraski — 2010-03-23T20:31:09+00:00 URL: https://externals.io/message/47486#47508 · In reply to: #47502 At 21:43 23/03/2010, Antony Dovgal wrote: > > […] > >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. > > […] > >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 --- ## #47509 — jerome@loyet.net — 2010-03-23T20:44:41+00:00 URL: https://externals.io/message/47486#47509 · In reply to: #47508 2010/3/23 Zeev Suraski : > At 21:43 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. > > > […] > > 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 --- ## #47510 — Michael Shadle — 2010-03-23T20:52:40+00:00 URL: https://externals.io/message/47486#47510 · In reply to: #47509 2010/3/23 Jérôme Loyet : > 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) --- ## #47511 — Zeev Suraski — 2010-03-23T20:54:14+00:00 URL: https://externals.io/message/47486#47511 · In reply to: #47509 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 --- ## #47512 — Antony Dovgal — 2010-03-23T20:55:46+00:00 URL: https://externals.io/message/47486#47512 · In reply to: #47508 > 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 --- ## #47515 — Zeev Suraski — 2010-03-23T21:02:02+00:00 URL: https://externals.io/message/47486#47515 At 22:58 23/03/2010, Antony Dovgal wrote: > > > […] > >The point is the XML syntax is already there and it's working fine, thank you. >No need to implement something on top of >something that wasn't supposed to be used this way. Anthony, You can't end discussions like that. The XML syntax may be there, but the FPM extension isn't a part of PHP, and I think what you're hearing is that in order to make it a part of PHP, it needs to conform to the way we do things in PHP - which does not involve XML configuration files. Zeev --- ## #47514 — Michael Shadle — 2010-03-23T21:03:54+00:00 URL: https://externals.io/message/47486#47514 · In reply to: #47512 > 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. --- ## #47516 — Zeev Suraski — 2010-03-23T21:05:52+00:00 URL: https://externals.io/message/47486#47516 · In reply to: #47512 At 22:55 23/03/2010, Antony Dovgal wrote: > > > […] > >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) option... anotheroption... [pool1] option... anotheroption... [pool2] option... anotheroption... > > […] > >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. > > […] > >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 --- ## #47518 — Antony Dovgal — 2010-03-23T21:58:25+00:00 URL: https://externals.io/message/47486#47518 · In reply to: #47516 > > […] > > 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 --- ## #47520 — Derick Rethans — 2010-03-23T22:01:31+00:00 URL: https://externals.io/message/47486#47520 · In reply to: #47515 > At 22:58 23/03/2010, Antony Dovgal wrote: > > > […] > > You can't end discussions like that. The XML syntax may be there, but > the FPM extension isn't a part of PHP, and I think what you're hearing > is that in order to make it a part of PHP, it needs to conform to the > way we do things in PHP - which does not involve XML configuration > files. I don't see how this actually matters. None of the other SAPIs are configured with a php.ini syntax. That includes IIS, Apache, Lighttpd and others. This is more of a webserver thing than a "PHP thing" so I don't see how it is relevant to require php.ini syntax if this XML configure file works just fine already. I mean, it'd be *nice* to have a non-XML syntax, but for me this is definitely not a requirement for FPM to be added to trunk. If you (or somebody else) wants a php.ini syntax for it, a patch can be written. It's Open Source after all. with kind regards, Derick -- http://derickrethans.nl | http://xdebug.org Like Xdebug? Consider a donation: http://xdebug.org/donate.php twitter: @derickr and @xdebug --- ## #47521 — Michael Shadle — 2010-03-23T22:03:11+00:00 URL: https://externals.io/message/47486#47521 · In reply to: #47518 > 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 --- ## #47523 — dreamcat four — 2010-03-23T22:04:14+00:00 URL: https://externals.io/message/47486#47523 · In reply to: #47512 > 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 Dovgal > --- > http://pinba.org - realtime statistics for PHP --- ## #47525 — Zeev Suraski — 2010-03-23T22:08:11+00:00 URL: https://externals.io/message/47486#47525 · In reply to: #47518 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 --- Next page: https://externals.io/message/47486.md?page=2