Re: [PHP-DEV] FPM RFC
On Tue, 23 Mar 2010, Antony Dovgal wrote: 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. 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] FPM RFC
2010/3/24 dreamcat four dreamc...@gmail.com: Wait a sec, As a previous maintainer, I dont believe I should really have as much weight in this decision as the rest of the internals group. It does seem like plenty enough discussion over this INI business. Theres now over 40+ mails on this thread, mostly about ini. And this is not the only discussion we ever had about this either. I agree with Stainslav that we shouldnt let it go unresolved because... well, because thats exactly what happened when we discussed ini files for FPM last time. I agree with you here. The last time we talked about that, it ended nowhere. it seems to be a passionate debate, so lets end it once and for all. Overall, it seems the positions of Stainslav and Zeev are generally representative of this thread. I don't have any worthwhile arguments throw against those views. They all seem balanced and well intentioned enough. And it would be great to draw a line under the whole RFC. Ie by stating that we only need to add just 1 specific feature to FPM to get it officially accepted. Now that Zeev (and if not Zeev then Stainslav) have been kind enough to openly commit to writing a patch for this, thats absolutely great progress. Of course we also dont want to miss out on all the major rewrite work Antony has been doing recently with FPM, which is also absoultely essential to a future with FPM. Its understandable to be worried about letting the standards of the code slip, when Antony has been trying so hard to clean up the existing codebase. So its not unreasonable unreasonable to be a little concerned that we would make the code harder to maintain by including INI syntax. Some of the struggle seems not adding INI, but adding it in a way thats clean and easy to maintain. On the other side of the coin, rejecting Zeevs offer for a patch would mean failing to satisfy the RFC consensus. Surely we can know what kind of good code to expect with Zeev and Stainslav here, based on their past work for PHP? If the problem is all arguing over these finer points / differences then id suggest that those seem less like big issues to the rest of us. Either way, this INI thing does seem to be pretty much the only thing people are asking for here. So it seems accurate (to me) to label any reasonable INI syntax as the 1 resulting RFC consensus? That would mean the RFC is not necessarily be an outright requirement to remove the xml. I mean you might conceivably want xml to remain for a while as a legacy option. Or have it the other way round, where the INI option is disabled by default until we are confident that it properly satisfies the RFC. About INI, we heard differents syntaxes (with or without sections, dot separation, ...). I made some conf file exemple to really see what it will be: ** Full Verbose ** It means that eveything is prefixed by the pool name (like pool.www_site_com.group = www). I added also the same conf file with includes: http://www.fatbsd.com/fpm/ini_full_verbose.html http://www.fatbsd.com/fpm/ini_full_verbose_with_includes.html ** Sections ** In this case, each pool is identified by a section. This way, we can use dot and space in pool name and we remove useless redundancies in keys (pool.www_site_com.user = www become user = www). If there is less redundancy, this is easier to read and write. I added also the same conf file with includes. http://www.fatbsd.com/fpm/ini_with_sections.html http://www.fatbsd.com/fpm/ini_with_sections_and_includes.html ** Default Section ** Talking about redundancy. When there is more than one pool, there is several parameters which remain the same. Why should we type them several time ? The idea is to define a special pool, which will not be started but only be used as a template with default values for other pools. Common parameters will be set in the default pool and in each pool only specifics parameters will be set. here some example in the two previous cases http://www.fatbsd.com/fpm/ini_full_verbose_and_default.html http://www.fatbsd.com/fpm/ini_full_verbose_and_default_and_include.html http://www.fatbsd.com/fpm/ini_with_sections_and_default.html http://www.fatbsd.com/fpm/ini_with_sections_and_default_and_include.html From my point of vue, a conf file should be the less redundant as possible and should be splitable in different files (in the case of huge conf file, or when several administrators work on the conf files, each pool has a file, and each pool administrator manage its own file). So the INI syntax with sections to seraparate pools, with include and the default pool is, for me, the best options we have here. It's quite simple, it's clear and customizable. To compare, I put the same in the current XML syntax : http://www.fatbsd.com/fpm/xml.html what do you think ? ++ Jerome On Wed, Mar 24, 2010 at 8:46 AM, Antony Dovgal t...@daylessday.org wrote: On 24.03.2010 11:29, Zeev Suraski wrote: I think you're missing something. I don't care
Re: [PHP-DEV] FPM RFC
2010/3/25 Jérôme Loyet jer...@loyet.net: ** Default Section ** Talking about redundancy. When there is more than one pool, there is several parameters which remain the same. Why should we type them several time ? The idea is to define a special pool, which will not be started but only be used as a template with default values for other pools. Common parameters will be set in the default pool and in each pool only specifics parameters will be set. here some example in the two previous cases Redundancy can be addressed by includes. I was thinking of creating an RFC for php.ini file support of includes, but FPM should support includes either - whether it is it's own INI file, the same XML file it's always been, whatever. It should be added to the FPM RFC. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] FPM RFC
On 25.03.2010 21:30, Michael Shadle wrote: 2010/3/25 Jérôme Loyet jer...@loyet.net: ** Default Section ** Talking about redundancy. When there is more than one pool, there is several parameters which remain the same. Why should we type them several time ? The idea is to define a special pool, which will not be started but only be used as a template with default values for other pools. Common parameters will be set in the default pool and in each pool only specifics parameters will be set. here some example in the two previous cases Redundancy can be addressed by includes. I was thinking of creating an RFC for php.ini file support of includes, but FPM should support includes either - whether it is it's own INI file, the same XML file it's always been, whatever. It should be added to the FPM RFC. You can as well stop declaring (!?) what FPM should and what it shoud not and start doing something useful instead. Writing some code might be a good start for you. -- Wbr, Antony Dovgal --- http://pinba.org - realtime statistics for PHP -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] FPM RFC
On Thu, Mar 25, 2010 at 12:47 PM, Antony Dovgal t...@daylessday.org wrote: You can as well stop declaring (!?) what FPM should and what it shoud not and start doing something useful instead. Writing some code might be a good start for you. As someone Andrei somewhat entrusted to try to keep the dream of FPM alive, I'll Also, I am an avid user and spokesperson for FPM. I don't write C, and I wouldn't attempt to write C for something as important as a daemon that supports heavily loaded websites (furthermore, why would you want me to start there) - I contribute any way I can, which has included [a little] money [and offers of more, but nobody has accepted], time, and support. I've offered different build environments (if we had any need for automated testing) I have a lot of resources available, just not coding. I'll ignore your elitist comment. RFCs should be open for anyone, as should discussions, and I am not declaring what it should do any more than anyone else with any ideas. If you want a coders only thing maybe this open source project should be taken behind closed doors and only those people who have proven themselves worthy of commenting on anything (who cares about the users? they're only the majority of the open source world) can be allowed to participate. Also I don't remember declaring anything. My comments about includes are the same kind of thing -anyone- can interject. I guess I just don't have enough karma to be valued in your world. I have done nothing but be appreciative and respectful of you, and always take your opinion as more informed as mine. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] FPM RFC
2010/3/25 Jérôme Loyet jer...@loyet.net: I made some conf file exemple to really see what it will be: snip http://www.fatbsd.com/fpm/ini_with_sections_and_default_and_include.html From my point of vue, a conf file should be the less redundant as possible and should be splitable in different files (in the case of huge conf file, or when several administrators work on the conf files, each pool has a file, and each pool administrator manage its own file). So the INI syntax with sections to seraparate pools, with include and the default pool is, for me, the best options we have here. It's quite simple, it's clear and customizable. To compare, I put the same in the current XML syntax : http://www.fatbsd.com/fpm/xml.html what do you think ? ++ Jerome http://www.fatbsd.com/fpm/ini_with_sections_and_default_and_include.html Hey, Thats the ticket Jerome! Maybe we have our winning INI scheme yet eh? Maybe id suggest (on top of that scheme), the main config file (which you labelled /etc/fpm.conf), to need only just the overidden options users want? So therefore the factory defaults file would be included earlier on, and tucked away somewhere else? Apart from that 1 suggestion, I cant see anything to improve upon. The standard seems good. I dont know if the whole internals list and / or Antony would agree but in anycase, this thread seems pretty exhausted now. If you intend to implement this Jerome, then perhaps (any time when / after you implement), just make new (seperate) RFC for that (just the ini). Which (obviously) can be attached as single dependancy of this RFC. That way, those comments / feedback can come directed back for just you (on your chosen, preferred ini implementation). And we don't get confused over the other ini examples. Best regards dreamcat4 dreamc...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] FPM RFC
2010/3/25 Michael Shadle mike...@gmail.com: 2010/3/25 dreamcat four dreamc...@gmail.com: If you intend to implement this Jerome, then perhaps (any time when / after you implement), just make new (seperate) RFC for that (just the ini). Which (obviously) can be attached as single dependancy of this RFC. That way, those comments / feedback can come directed back for just you (on your chosen, preferred ini implementation). And we don't get confused over the other ini examples. I agree this does look decent and supports includes (/me is happy) One thing - can the main fpm.conf be defined in php.ini? Instead of at compile time? Is there any sapi with directives in php.ini ? I can't see any reasons to have some FPM specifics into php.ini. To change the default conf file, juste specified it in the commande line like any other daemon you have running on your boxes. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] FPM RFC
2010/3/25 dreamcat four dreamc...@gmail.com: If you intend to implement this Jerome, then perhaps (any time when / after you implement), just make new (seperate) RFC for that (just the ini). Which (obviously) can be attached as single dependancy of this RFC. That way, those comments / feedback can come directed back for just you (on your chosen, preferred ini implementation). And we don't get confused over the other ini examples. I agree this does look decent and supports includes (/me is happy) One thing - can the main fpm.conf be defined in php.ini? Instead of at compile time? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] FPM RFC
2010/3/25 Jérôme Loyet jer...@loyet.net: Is there any sapi with directives in php.ini ? I can't see any reasons to have some FPM specifics into php.ini. To change the default conf file, juste specified it in the commande line like any other daemon you have running on your boxes. php-fpm isn't launched manually like a daemon on the box. it's actually using the script that is dynamically generated when doing ./configure i just think for configurability it would be nice to point where the fpm location would be, instead of making daemon arguments... and yes there are sapi directives all over in php.ini. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] FPM RFC
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 s...@zend.com http://www.zend.com/ (408)253-8829 MSN: s...@zend.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] FPM RFC
Hi! That's not true. You configure the fastcgi SAPI for lighttpd in the lighttpd config, in LUA. Sure, it's the web-server side of it, but it's no different from sapi/fpm which is its own little wrapper instead of the one that comes with lighttpd. Actually, it is different. lighty is not a part of PHP, and lives entirely independent, only thing PHP needs from it is the process to be started and communication through standard protocol. Here we have full server configuration inside PHP. you even allow it to be in. And feedback can also come in patches if you really find it so important to have a .ini syntax. I'm sure I could patch that and many others here could too, but here the problem is reaching consensus on the question and not writing a patch. If you're telling there's already consensus and the only problem is not having the patch - it'd be entirely different question, but I think we're far from being there. And writing a patch that extension maintainer explicitly opposes to sounds like waste of time... - If somebody finds it necessary, write the code for it and we can discuss whether we actually want a .ini file like syntax. We're already doing it now (discussing), why not finish it? -- Stanislav Malyshev, Zend Software Architect s...@zend.com http://www.zend.com/ (408)253-8829 MSN: s...@zend.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] FPM RFC
2010/3/23 Stanislav Malyshev s...@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/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] FPM RFC
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 s...@zend.com http://www.zend.com/ (408)253-8829 MSN: s...@zend.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] FPM RFC
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 s...@zend.com http://www.zend.com/ (408)253-8829 MSN: s...@zend.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] FPM RFC
On 24.03.2010, at 0:58, Antony Dovgal wrote: On 24.03.2010 00:05, Zeev Suraski wrote: 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 ;) -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] FPM RFC
On 24.03.2010 09:36, Stanislav Malyshev wrote: fpm.myworker.server.start_servers = 20 fpm.myworker.php_defines.memory_limit = 64M etc. 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] FPM RFC
On 24.03.2010 01:16, Zeev Suraski wrote: For me it is a requirement before the code makes it into a released version of PHP, and I think many others think that way if past discussions are any indication. That's what RFCs are for - if people can just go ahead and implement their original thoughts without paying attention to feedback, why bother? Personally I think that the person pushing the code should be responsible for implementing the feedback to the RFC (or getting others to do it). I think you're missing something. I don't care if FPM is in or out of the core. The only thing I get in case if it's accepted is more troubles as I'll have to maintain it. Nevertheless, I feel that it's a good thing, therefore I'm pushing it in. But if somebody wants me to rewrite a substantial and well-tested part of the code in order to use another syntax style just because XML is too complex for mere mortals - I won't do it. If there are any volunteers to do this - go ahead, let's see what happens. If there are none - fine, I have enough stuff to maintain already. -- Wbr, Antony Dovgal --- http://pinba.org - realtime statistics for PHP -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] FPM RFC
At 10:21 24/03/2010, Antony Dovgal wrote: On 24.03.2010 01:16, Zeev Suraski wrote: For me it is a requirement before the code makes it into a released version of PHP, and I think many others think that way if past discussions are any indication. That's what RFCs are for - if people can just go ahead and implement their original thoughts without paying attention to feedback, why bother? Personally I think that the person pushing the code should be responsible for implementing the feedback to the RFC (or getting others to do it). I think you're missing something. I don't care if FPM is in or out of the core. FWIW, I don't think it's a good start for a component that goes into our distribution. In this case I'm willing to take responsibility for doing the conversion, but for the record, if someone proposes to put a component into the PHP distro and refuses to implement the feedback (not every last piece of anecdotal feedback, but the key points) because it's not important enough in his view, I do think it should preclude the component from being accepted. We have the RFC process for a reason. Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] FPM RFC
On 24.03.2010 11:29, Zeev Suraski wrote: I think you're missing something. I don't care if FPM is in or out of the core. FWIW, I don't think it's a good start for a component that goes into our distribution. In this case I'm willing to take responsibility for doing the conversion, but for the record, if someone proposes to put a component into the PHP distro and refuses to implement the feedback (not every last piece of anecdotal feedback, but the key points) Key points is exactly what under question here. Taking into account that the maintainer of the branch (along with other people) agrees with me, I tend to think this point is not so major as you think. -- Wbr, Antony Dovgal --- http://pinba.org - realtime statistics for PHP -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] FPM RFC
At 10:46 24/03/2010, Antony Dovgal wrote: On 24.03.2010 11:29, Zeev Suraski wrote: I think you're missing something. I don't care if FPM is in or out of the core. FWIW, I don't think it's a good start for a component that goes into our distribution. In this case I'm willing to take responsibility for doing the conversion, but for the record, if someone proposes to put a component into the PHP distro and refuses to implement the feedback (not every last piece of anecdotal feedback, but the key points) Key points is exactly what under question here. Taking into account that the maintainer of the branch (along with other people) agrees with me, I tend to think this point is not so major as you think. I think we've exhausted that discussion already, we can agree to disagree. Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] FPM RFC
Wait a sec, As a previous maintainer, I dont believe I should really have as much weight in this decision as the rest of the internals group. It does seem like plenty enough discussion over this INI business. Theres now over 40+ mails on this thread, mostly about ini. And this is not the only discussion we ever had about this either. I agree with Stainslav that we shouldnt let it go unresolved because... well, because thats exactly what happened when we discussed ini files for FPM last time. Overall, it seems the positions of Stainslav and Zeev are generally representative of this thread. I don't have any worthwhile arguments throw against those views. They all seem balanced and well intentioned enough. And it would be great to draw a line under the whole RFC. Ie by stating that we only need to add just 1 specific feature to FPM to get it officially accepted. Now that Zeev (and if not Zeev then Stainslav) have been kind enough to openly commit to writing a patch for this, thats absolutely great progress. Of course we also dont want to miss out on all the major rewrite work Antony has been doing recently with FPM, which is also absoultely essential to a future with FPM. Its understandable to be worried about letting the standards of the code slip, when Antony has been trying so hard to clean up the existing codebase. So its not unreasonable unreasonable to be a little concerned that we would make the code harder to maintain by including INI syntax. Some of the struggle seems not adding INI, but adding it in a way thats clean and easy to maintain. On the other side of the coin, rejecting Zeevs offer for a patch would mean failing to satisfy the RFC consensus. Surely we can know what kind of good code to expect with Zeev and Stainslav here, based on their past work for PHP? If the problem is all arguing over these finer points / differences then id suggest that those seem less like big issues to the rest of us. Either way, this INI thing does seem to be pretty much the only thing people are asking for here. So it seems accurate (to me) to label any reasonable INI syntax as the 1 resulting RFC consensus? That would mean the RFC is not necessarily be an outright requirement to remove the xml. I mean you might conceivably want xml to remain for a while as a legacy option. Or have it the other way round, where the INI option is disabled by default until we are confident that it properly satisfies the RFC. On Wed, Mar 24, 2010 at 8:46 AM, Antony Dovgal t...@daylessday.org wrote: On 24.03.2010 11:29, Zeev Suraski wrote: I think you're missing something. I don't care if FPM is in or out of the core. FWIW, I don't think it's a good start for a component that goes into our distribution. In this case I'm willing to take responsibility for doing the conversion, but for the record, if someone proposes to put a component into the PHP distro and refuses to implement the feedback (not every last piece of anecdotal feedback, but the key points) Key points is exactly what under question here. Taking into account that the maintainer of the branch (along with other people) agrees with me, I tend to think this point is not so major as you think. -- Wbr, Antony Dovgal --- http://pinba.org - realtime statistics for PHP -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] FPM RFC
On 03/23/2010 08:15 PM, Jani Taskinen wrote:
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. :)
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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] FPM RFC
On Tue, Mar 23, 2010 at 10:25 AM, Antony Dovgal t...@daylessday.org wrote: 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. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] FPM RFC
2010/3/23 Michael Shadle mike...@gmail.com: On Tue, Mar 23, 2010 at 10:25 AM, Antony Dovgal t...@daylessday.org wrote: 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 :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. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] FPM RFC
hi Tony,
On Tue, Mar 23, 2010 at 6:25 PM, Antony Dovgal t...@daylessday.org 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.
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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] FPM RFC
On 03/23/2010 10:26 PM, Michael Shadle 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. - 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] FPM RFC
On 03/23/2010 10:37 PM, Pierre Joye wrote:
hi Tony,
On Tue, Mar 23, 2010 at 6:25 PM, Antony Dovgal t...@daylessday.org 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.
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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] FPM RFC
Antony Dovgal wrote: On 03/23/2010 10:26 PM, Michael Shadle 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.jo...@oracle.com Tel: +1 650 506 8630 Blog: http://blogs.oracle.com/opal/ Free PHP Book: http://tinyurl.com/ugpomhome -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] FPM RFC
On Tue, Mar 23, 2010 at 12:43 PM, Antony Dovgal t...@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? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] FPM RFC
On Tue, Mar 23, 2010 at 4:09 PM, Michael Shadle mike...@gmail.com wrote: On Tue, Mar 23, 2010 at 12:43 PM, Antony Dovgal t...@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? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php 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
Re: [PHP-DEV] FPM RFC
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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] FPM RFC
2010/3/23 Jérôme Loyet jer...@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) -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] FPM RFC
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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] FPM RFC
On 03/23/2010 11:31 PM, Zeev Suraski 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=292487view=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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] FPM RFC
On 03/23/2010 11:54 PM, Zeev Suraski wrote: 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. 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. -- Wbr, Antony Dovgal --- http://pinba.org - realtime statistics for PHP -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] FPM RFC
On Tue, Mar 23, 2010 at 1:55 PM, Antony Dovgal t...@daylessday.org wrote: 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. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] FPM RFC
At 22:58 23/03/2010, Antony Dovgal wrote: On 03/23/2010 11:54 PM, Zeev Suraski wrote: 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. 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] FPM RFC
At 22:55 23/03/2010, Antony Dovgal wrote: On 03/23/2010 11:31 PM, Zeev Suraski 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=292487view=markuphttp://svn.php.net/viewvc/php/php-src/branches/PHP_5_3_FPM/sapi/fpm/php-fpm.conf.in?revision=292487view=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... 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] FPM RFC
On 24.03.2010 00:05, Zeev Suraski wrote: 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] FPM RFC
On Tue, 23 Mar 2010, Zeev Suraski wrote: At 22:58 23/03/2010, Antony Dovgal wrote: On 03/23/2010 11:54 PM, Zeev Suraski wrote: 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. 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. 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] FPM RFC
On Tue, Mar 23, 2010 at 2:58 PM, Antony Dovgal t...@daylessday.org wrote:
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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] FPM RFC
On Tue, Mar 23, 2010 at 8:55 PM, Antony Dovgal t...@daylessday.org wrote: 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] FPM RFC
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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] FPM RFC
At 00:01 24/03/2010, Derick Rethans wrote: I don't see how this actually matters. None of the other SAPIs are configured with a php.ini syntax. None of the other SAPIs are configured, period; The little configuration they do have is done using php.ini. This SAPI requires much more configuration - and I agree it's equivalent to web server configuration - but given that it's going to be bundled in PHP, it should use the same 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. For me it is a requirement before the code makes it into a released version of PHP, and I think many others think that way if past discussions are any indication. That's what RFCs are for - if people can just go ahead and implement their original thoughts without paying attention to feedback, why bother? Personally I think that the person pushing the code should be responsible for implementing the feedback to the RFC (or getting others to do it). Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] FPM RFC
On 24.03.2010 01:08, Zeev Suraski 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. 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] FPM RFC
On Wed, 24 Mar 2010, Zeev Suraski wrote: At 00:01 24/03/2010, Derick Rethans wrote: I don't see how this actually matters. None of the other SAPIs are configured with a php.ini syntax. None of the other SAPIs are configured, period. That's not true. You configure the fastcgi SAPI for lighttpd in the lighttpd config, in LUA. Sure, it's the web-server side of it, but it's no different from sapi/fpm which is its own little wrapper instead of the one that comes with lighttpd. ## Start an FastCGI server for php fastcgi.server= ( .php = (( bin-path = /usr/local/php/5.3dev/bin/php-cgi, socket = /tmp/php80.socket, max-procs = 1, idle-timeout = 20, bin-environment = ( PHP_FCGI_CHILDREN = 1, PHP_FCGI_MAX_REQUESTS = 1 ), bin-copy-environment = ( PATH, SHELL, USER ), broken-scriptfilename = enable )) ) This is in no way different than doing the configuration for the FPM sapi in their XML file. This SAPI requires much more configuration - and I agree it's equivalent to web server configuration - but given that it's going to be bundled in PHP, it should use the same 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. For me it is a requirement before the code makes it into a released version of PHP We're not nearly close to a release. , and I think many others think that way if past discussions are any indication. That's what RFCs are for - if people can just go ahead and implement their original thoughts without paying attention to feedback, why bother? Personally I think that the person pushing the code should be responsible for implementing the feedback to the RFC (or getting others to do it). But I don't think they should just blatently pick up on any suggestion that comes in through the mailinglist. Feedback is good, but that doesn't mean all of it should be taken into account in the code before you even allow it to be in. And feedback can also come in patches if you really find it so important to have a .ini syntax. My take on this is: - Add sapi/fpm to trunk; it's standalone, it works - If somebody finds it necessary, write the code for it and we can discuss whether we actually want a .ini file like syntax. with kind regards, Derick -- http://derickrethans.nl | http://xdebug.org Like Xdebug? Consider a donation: http://xdebug.org/donate.php twitter: @derickr and @xdebug -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] FPM RFC
On Tue, Mar 23, 2010 at 10:16 PM, Zeev Suraski z...@zend.com wrote: At 00:01 24/03/2010, Derick Rethans wrote: I don't see how this actually matters. None of the other SAPIs are configured with a php.ini syntax. None of the other SAPIs are configured, period; The little configuration they do have is done using php.ini. This SAPI requires much more configuration - and I agree it's equivalent to web server configuration - but given that it's going to be bundled in PHP, it should use the same syntax. Maybe its valid to make an exception for FPM, given that it has an exceptional number of configuration options. I would ask, how easy is PHP.ini to debug? One great thing about the nginx configuration parser is that it gives decent error messages when you've got the config all wrong. But in any case I dont believe you should require Antony to implement this if its out of his area of expertise, and there are plenty of other people around who can contribute the code better / more enthusiastically. 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. For me it is a requirement before the code makes it into a released version of PHP, and I think many others think that way if past discussions are any indication. That's what RFCs are for - if people can just go ahead and implement their original thoughts without paying attention to feedback, why bother? Personally I think that the person pushing the code should be responsible for implementing the feedback to the RFC (or getting others to do it). Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] FPM RFC
On Tue, Mar 23, 2010 at 11:33 PM, Derick Rethans der...@php.net wrote: That's not true. You configure the fastcgi SAPI for lighttpd in the lighttpd config, in LUA. Sure, it's the web-server side of it, but it's no different from sapi/fpm which is its own little wrapper instead of the one that comes with lighttpd. ## Start an FastCGI server for php fastcgi.server = ( .php = bin-copy-environment = ( PATH, SHELL, USER ), broken-scriptfilename = enable )) ) This is in no way different than doing the configuration for the FPM sapi in their XML file. That's not true either. That's clearly a server configuration and has absolutely nothing to do with PHP. It is a FastCGI configuration (in this case for lighttpd) and it will work the same for any other FastCGI (environment settings may differ but the way to do it does not). It is slightly different with mod_php as php actually extends the configuration syntax of Apache. But that's pretty much the same than with fastcgi. What I would suggest is to get it into trunk soon so we can test it more easily. About the configuration format, it seems to me that we should figure out a way to do it in php.ini for consistency. But for my own sanity, please don't bring XML to the game. If a more flexible format is required, please consider YAML. However, is it not possible to extend our ini parser to support what we need for FPM (did not check all the details)? Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] FPM RFC
At 00:33 24/03/2010, Derick Rethans wrote: On Wed, 24 Mar 2010, Zeev Suraski wrote: At 00:01 24/03/2010, Derick Rethans wrote: I don't see how this actually matters. None of the other SAPIs are configured with a php.ini syntax. None of the other SAPIs are configured, period. That's not true. You configure the fastcgi SAPI for lighttpd in the lighttpd config, in LUA. Sure, it's the web-server side of it, but it's no different from sapi/fpm which is its own little wrapper instead of the one that comes with lighttpd. I think it's very different. Would we include that LUA code in PHP? That's the difference. It's going to become a part of PHP, it's going to be supported by PHP, it should use the same mechanisms as the rest of PHP. My take on this is: - Add sapi/fpm to trunk; it's standalone, it works - If somebody finds it necessary, write the code for it and we can discuss whether we actually want a .ini file like syntax. I think there was substantial opposition to keeping the XML-based configuration file. The obvious default was .ini-syntax, and now that it's clear it's very much a viable option - I think we should go for it. I think keeping it as XML and then putting the burden of moving it to another format the many people that commented on the RFC - after they write the code, no less - is not reasonable. My take: - Put it in trunk, subject to change in the configuration file format before it gets released. Principals aside, I can take care of moving it to .ini format. Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
