Re: [PHP-DEV] FastCGI limit memory
Andi Gutmans wrote: Don't the FastCGI processes inherit memory limits from their parent? (assuming you're not running standalone FastCGI which almost noone does). Nope, the parent (master) process only keeps the track of active childs (usually I spawn like 250 of them) and distributes the incoming requests. As far as I understand each child operates on its own. rr -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] [SPAM] Re: [PHP-DEV] Syntactic improvement to array
On 05 February 2007 17:29, Brian Moon wrote:
Ford, Mike wrote:
I don't find:
$a = [1 = ['pears', 'apples'], 2 = ['juice', 'oranges']];
any less readable than:
$a = array(1 = array('pears', 'apples'), 2 = array('juice',
'oranges'));
Quite the opposite actually :)
Me too - I go beyond Edin on this one, as I find the
array() version actually quite UNreadable and I have
difficulty picking out what the individual arrays are;
conversely, the [] version I take in at a glance.
That is why you have coding standards. Our doucment states that this
should be written as:
$a = array(
1 = array('pears', 'apples'),
2 = array('juice', 'oranges')
);
I believe in either syntax, proper formatting of complex data
can solve
the readablity problems.
Solve, no. Alleviate, yes.
Given the above, the layout tells me there's some kind of structure
going on, but I still have to actually *read* it to discover
that there are arrays involved (and where they start and end).
With this version:
$a = [
1 = ['pears', 'apples'],
2 = ['juice', 'oranges']
];
I can take one glance and tell there are nested arrays involved, and
what their scopes are -- I'd say my comprehension speed is at least
an order of magnitude faster!
*That* makes this syntax a no-brainer for me, personally ;-)
Cheers!
Mike
-
Mike Ford, Electronic Information Services Adviser,
Learning Support Services, Learning Information Services,
JG125, James Graham Building, Leeds Metropolitan University,
Headingley Campus, LEEDS, LS6 3QS, United Kingdom
Email: [EMAIL PROTECTED]
Tel: +44 113 283 2600 extn 4730 Fax: +44 113 283 3211
To view the terms under which this email is distributed, please go to
http://disclaimer.leedsmet.ac.uk/email.htm
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] RE : [PHP-DEV] Re: Syntactic improvement to array
From: Richard Lynch How many newbies will be trying: array[1, 2, 3]; and left scratching their heads when it doesn't work? Yes, even if I am in favor of the [] syntax, it is a good argument: 'array[ 1, 2, 3]' can become a very common error, and not especially among newbies! Maybe I am wrong, but would it be possible to accept all these syntaxes : array(1, 2, 3) (RHS only) [ 1, 2, 3 ] (RHS=array / LHS=list, I especially like: '$x = [ $a, $b ] = f()' :) list($a, $b)(LHS only) array[1, 2, 3] (RHS only) For this purpose, we could say that the [] notation is optionally preceded by 'array'. Another idea if you want to make it easier to understand for newbies: make array() and list() synonyms, so that array() behaves as list() when LHS, and list() behaves as array() when RHS. IMHO, it would become simpler to explain. If we implement both, we can even suppport 'list[ 1, 2, 3 ]'. How can we be more permissive? Regards Francois -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Removing if: endif; syntax
On 05 February 2007 17:32, Brian Moon wrote: Reading the array thread, someone mentioned having several ways of doing things. One of their examples was the if: endif; syntax. Forgive me if this has been discussed, but has anyone proposed removing that for PHP6? Seems like the perfect time to do it. Its not recommended. Editors that check PHP syntax warn about it. It just seems like a no brainer. =) Please don't. I have several tens of thousands of lines of code using this syntax, and I really, really would not want to have to rewrite them into the less readable, less maintainable pure curly brackets form (which I hate with a passion!). Cheers! Mike - Mike Ford, Electronic Information Services Adviser, Learning Support Services, Learning Information Services, JG125, James Graham Building, Leeds Metropolitan University, Headingley Campus, LEEDS, LS6 3QS, United Kingdom Email: [EMAIL PROTECTED] Tel: +44 113 283 2600 extn 4730 Fax: +44 113 283 3211 To view the terms under which this email is distributed, please go to http://disclaimer.leedsmet.ac.uk/email.htm -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] [SPAM] Re: [PHP-DEV] Syntactic improvement to array
On Tue, 2007-02-06 at 14:08 +, Ford, Mike wrote:
On 05 February 2007 17:29, Brian Moon wrote:
That is why you have coding standards. Our doucment states that this
should be written as:
$a = array(
1 = array('pears', 'apples'),
2 = array('juice', 'oranges')
);
I believe in either syntax, proper formatting of complex data
can solve
the readablity problems.
Solve, no. Alleviate, yes.
Given the above, the layout tells me there's some kind of structure
going on, but I still have to actually *read* it to discover
that there are arrays involved (and where they start and end).
With this version:
$a = [
1 = ['pears', 'apples'],
2 = ['juice', 'oranges']
];
I can take one glance and tell there are nested arrays involved, and
what their scopes are -- I'd say my comprehension speed is at least
an order of magnitude faster!
*That* makes this syntax a no-brainer for me, personally ;-)
Ummm, you still had to read it. One glance just so happens to involve
the brain grokking the content, just like reading.
Cheers,
Rob.
--
..
| InterJinn Application Framework - http://www.interjinn.com |
::
| An application and templating framework for PHP. Boasting |
| a powerful, scalable system for accessing system services |
| such as forms, properties, sessions, and caches. InterJinn |
| also provides an extremely flexible architecture for |
| creating re-usable components quickly and easily. |
`'
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [SPAM] Re: [PHP-DEV] Syntactic improvement to array
On Tue, Feb 06, 2007 at 09:41:34AM -0500, Robert Cummings wrote:
On Tue, 2007-02-06 at 14:08 +, Ford, Mike wrote:
On 05 February 2007 17:29, Brian Moon wrote:
That is why you have coding standards. Our doucment states that this
should be written as:
$a = array(
1 = array('pears', 'apples'),
2 = array('juice', 'oranges')
);
I believe in either syntax, proper formatting of complex data
can solve
the readablity problems.
Solve, no. Alleviate, yes.
Given the above, the layout tells me there's some kind of structure
going on, but I still have to actually *read* it to discover
that there are arrays involved (and where they start and end).
With this version:
$a = [
1 = ['pears', 'apples'],
2 = ['juice', 'oranges']
];
I can take one glance and tell there are nested arrays involved, and
what their scopes are -- I'd say my comprehension speed is at least
an order of magnitude faster!
*That* makes this syntax a no-brainer for me, personally ;-)
Ummm, you still had to read it. One glance just so happens to involve
the brain grokking the content, just like reading.
I must agree that the [] is easier/quicker to read than array(), but is it
really worth it ... too many syntaxes for the same thing ?
Anyway: it makes php look like perl -- and that would never do :-)
--
Alain Williams
Linux Consultant - Mail systems, Web sites, Networking, Programmer, IT Lecturer.
+44 (0) 787 668 0256 http://www.phcomp.co.uk/
Parliament Hill Computers Ltd. Registration Information:
http://www.phcomp.co.uk/contact.php
#include std_disclaimer.h
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [SPAM] Re: [PHP-DEV] Syntactic improvement to array
Alain Williams wrote: Anyway: it makes php look like perl -- and that would never do :-) Can we please stop that FUD? (even if it is meant as a joke) ... if at all then you might say it looks like Javascript, Python or Ruby. Perl uses an ugly mix of () and [] to emulate multi-dimensional arrays rather unlike the syntax proposed here. Thanks, - Chris -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [SPAM] Re: [PHP-DEV] Syntactic improvement to array
On Tue, Feb 06, 2007 at 04:16:28PM +0100, Christian Schneider wrote: Alain Williams wrote: Anyway: it makes php look like perl -- and that would never do :-) Can we please stop that FUD? (even if it is meant as a joke) No: it was NOT a serious point. What is wrong with the occasional grin ? ... if at all then you might say it looks like Javascript, Python or Ruby. Perl uses an ugly mix of () and [] to emulate multi-dimensional arrays rather unlike the syntax proposed here. Thanks, - Chris -- Alain Williams Linux Consultant - Mail systems, Web sites, Networking, Programmer, IT Lecturer. +44 (0) 787 668 0256 http://www.phcomp.co.uk/ Parliament Hill Computers Ltd. Registration Information: http://www.phcomp.co.uk/contact.php #include std_disclaimer.h -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Syntactic improvement to array
how it is different? How explaining array written as [] so much harder that explaining array written as ()? What exactly constitutes the problem? Here's the difference: You can Google for 'array' and learn a lot. If you try to Google for [] you don't learn squat. Try it and see. So our 'newbie' at least has a good chance of figuring out array(1, 2, 3) on their own. They've got must worse odds of figuring out [1,2,3] Ok. So I propose more searcheable operators: let($i, 1) === $i = 1 let($d, add($a, $b, $c)) === $d = $a + $b + $c call(foo, $arg1, $arg2)=== foo($arg1, $arg2) :-) Our 'newbie' at least has a good chance of figuring out $a = [1,2,3] vs.$a = array(1,2,3) is different than $a = foobar(1,2,3) -- Tullio Andreatta Disclaimer: Please treat this email message in a reasonable way, or we might get angry ( http://www.goldmark.org/jeff/stupid-disclaimers ) -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Syntactic improvement to array
Hi. Our 'newbie' at least has a good chance of figuring out $a = [1,2,3] vs.$a = array(1,2,3) is different than $a = foobar(1,2,3) I am probably out of my depth here...but I actually find the argument about wether to introduce this syntax or not, very entertaining...it's a classic example of human individuality. great really;) The argument against introducing the new syntax, that says, that it's less searchable,...well...why not improve the search functionality of the php-documentation? it would help with all the other operators (and magic functions and language constructs) if the search-function would try to match the search-input against operators and constructs, no? I know that google won't show anything worthwhile when queried about php [] or the like...but...the php-documentation is very good and maybe we could improve access to it...a newbie could then query all he wants in the php-doc page. No good? Lars -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] [SPAM] Re: [PHP-DEV] Syntactic improvement to array
On 06 February 2007 14:42, Robert Cummings wrote:
On Tue, 2007-02-06 at 14:08 +, Ford, Mike wrote:
On 05 February 2007 17:29, Brian Moon wrote:
That is why you have coding standards. Our doucment states that
this should be written as:
$a = array(
1 = array('pears', 'apples'),
2 = array('juice', 'oranges')
);
I believe in either syntax, proper formatting of complex data can
solve the readablity problems.
Solve, no. Alleviate, yes.
Given the above, the layout tells me there's some kind of structure
going on, but I still have to actually *read* it to discover
that there are arrays involved (and where they start and end).
With this version:
$a = [
1 = ['pears', 'apples'],
2 = ['juice', 'oranges']
];
I can take one glance and tell there are nested arrays involved, and
what their scopes are -- I'd say my comprehension speed is at least
an order of magnitude faster!
*That* makes this syntax a no-brainer for me, personally ;-)
Ummm, you still had to read it. One glance just so happens to
involve the brain grokking the content, just like reading.
No, I didn't have to read it. I had to look at it and see its shape, and I may
or may not have grokked it, but I didn't read it. I still have no idea what's
actually *in* the arrays, I just know there are arrays and how they're
structured. My brain, virtually instantaneously, goes, Oh, brackets, nested
arrays, 2 short arrays nested in an enclosing outer one!. I don't class that
as reading, just visual comprehension.
With the long version, my thought process goes more like Uh, oh, indentation,
must be some structure here. Can't see any obvious syntactic markers, just a
mush of characters, so better read it. 'array', uh, ok an array, what's in it?
explicit index 1 is, oh, 'array' again, ok, so we've got nested arrays,
presumably this line is a self-contained inner array? let's see, 'pears',
'apples', and, oh yes, a proper matching close parenthesis; next line similar,
explicit index 2, 'juice', 'oranges' and a close parenthesis, yup and a proper
closing parenthesis for the outer array; right, 2 short arrays nested in an
outer enclosing one. See how I've actually had to read and process *every*
*single* *word* *and* *character* on the page? See how much slower it was?
Now, that's what I call reading.
My brain may be weird and unusual in working this way, but it does so I've
become accustomed to it! I know it's off the norm in other areas (I have no
problem keeping a dozen or so PINs in my head and reliably producing the right
one without hesitation, and I generally remember personal ID, bank account and
credit card numbers without even trying) so it wouldn't surprise me to find I'm
way off the curve here too. Just permit me my little foibles, eh?
Cheers!
Mike
-
Mike Ford, Electronic Information Services Adviser,
Learning Support Services, Learning Information Services,
JG125, James Graham Building, Leeds Metropolitan University,
Headingley Campus, LEEDS, LS6 3QS, United Kingdom
Email: [EMAIL PROTECTED]
Tel: +44 113 283 2600 extn 4730 Fax: +44 113 283 3211
To view the terms under which this email is distributed, please go to
http://disclaimer.leedsmet.ac.uk/email.htm
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Syntactic improvement to array
On Feb 5, 2007, at 3:37 PM, Richard Lynch wrote: Yes, and it makes life miserable for some of us... Is that a good reason to extend that misery to yet another operator? Richard, please. This is not advanced OO stuff or anything close. It's an operator. Give PHP users (even newbies) some credit. -Andrei -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Syntactic improvement to array
That's because you wouldn't be using those words with a newbie, if you are smart. You'd simply say it works like list() here and it works like array() here. -Andrei On Feb 5, 2007, at 3:41 PM, Richard Lynch wrote: On Mon, February 5, 2007 12:06 pm, Andrei Zmievski wrote: On Feb 4, 2007, at 8:52 PM, Richard Lynch wrote: E! So now we have an invisible operator with a magical symbol '[' which *sometimes* means create an array, but *sometimes* means to de-construct an array into individual variables? That's just disgusting, imho. -1 !!! The way I view [] is that it creates an array context. When the context is an RHS, it instantiates an array. When it's an LHS, the context deconstructs the array. I can 'splain list() to a newbie and get them to understand it as an array deconstructor function thingie, and usually succeed in one or two tries to get it into their heads. I don't think I can do that with [] and LHS and RHS in anything like 2 tries... More like 10 times, probably. -- Some people have a gift link here. Know what I want? I want you to buy a CD from some starving artist. http://cdbaby.com/browse/from/lynch Yeah, I get a buck. So? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Syntactic improvement to array
Now you're just grandstanding.
-Andrei
On Feb 5, 2007, at 3:55 PM, Richard Lynch wrote:
More edge cases:
$foo = array(1, 2, 3];
$bar = [1, 2, 3);
Syntax error because it's unbalancedO
Or kosher, because the choice of start/end delimiters should be up to
the user?
Should it match whatever rule is in place for:
if (...){
endif;
--
Some people have a gift link here.
Know what I want?
I want you to buy a CD from some starving artist.
http://cdbaby.com/browse/from/lynch
Yeah, I get a buck. So?
--
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] [SPAM] Re: [PHP-DEV] Syntactic improvement to array
On Tue, 2007-02-06 at 15:41 +, Ford, Mike wrote:
On 06 February 2007 14:42, Robert Cummings wrote:
On Tue, 2007-02-06 at 14:08 +, Ford, Mike wrote:
On 05 February 2007 17:29, Brian Moon wrote:
That is why you have coding standards. Our doucment states that
this should be written as:
$a = array(
1 = array('pears', 'apples'),
2 = array('juice', 'oranges')
);
I believe in either syntax, proper formatting of complex data can
solve the readablity problems.
Solve, no. Alleviate, yes.
Given the above, the layout tells me there's some kind of structure
going on, but I still have to actually *read* it to discover
that there are arrays involved (and where they start and end).
With this version:
$a = [
1 = ['pears', 'apples'],
2 = ['juice', 'oranges']
];
I can take one glance and tell there are nested arrays involved, and
what their scopes are -- I'd say my comprehension speed is at least
an order of magnitude faster!
*That* makes this syntax a no-brainer for me, personally ;-)
Ummm, you still had to read it. One glance just so happens to
involve the brain grokking the content, just like reading.
No, I didn't have to read it. I had to look at it and see its shape, and I
may or may not have grokked it, but I didn't read it. I still have no idea
what's actually *in* the arrays, I just know there are arrays and how they're
structured. My brain, virtually instantaneously, goes, Oh, brackets, nested
arrays, 2 short arrays nested in an enclosing outer one!. I don't class
that as reading, just visual comprehension.
With the long version, my thought process goes more like Uh, oh,
indentation, must be some structure here. Can't see any obvious syntactic
markers, just a mush of characters, so better read it. 'array', uh, ok an
array, what's in it? explicit index 1 is, oh, 'array' again, ok, so we've got
nested arrays, presumably this line is a self-contained inner array? let's
see, 'pears', 'apples', and, oh yes, a proper matching close parenthesis;
next line similar, explicit index 2, 'juice', 'oranges' and a close
parenthesis, yup and a proper closing parenthesis for the outer array; right,
2 short arrays nested in an outer enclosing one. See how I've actually had
to read and process *every* *single* *word* *and* *character* on the page?
See how much slower it was? Now, that's what I call reading.
My brain may be weird and unusual in working this way, but it does so I've
become accustomed to it! I know it's off the norm in other areas (I have no
problem keeping a dozen or so PINs in my head and reliably producing the
right one without hesitation, and I generally remember personal ID, bank
account and credit card numbers without even trying) so it wouldn't surprise
me to find I'm way off the curve here too. Just permit me my little foibles,
eh?
Cheers!
I know how much you want to feel special, but here's the definition of
read. Your description of how you interpret what you see falls into
this definition:
http://209.161.37.11/dictionary/read
Cheers,
Rob.
--
..
| InterJinn Application Framework - http://www.interjinn.com |
::
| An application and templating framework for PHP. Boasting |
| a powerful, scalable system for accessing system services |
| such as forms, properties, sessions, and caches. InterJinn |
| also provides an extremely flexible architecture for |
| creating re-usable components quickly and easily. |
`'
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] FastCGI limit memory
Yeah but process limits are inherited after fork(). -Original Message- From: Reinis Rozitis [mailto:[EMAIL PROTECTED] Sent: Tuesday, February 06, 2007 3:28 AM To: internals@lists.php.net Subject: Re: [PHP-DEV] FastCGI limit memory Andi Gutmans wrote: Don't the FastCGI processes inherit memory limits from their parent? (assuming you're not running standalone FastCGI which almost noone does). Nope, the parent (master) process only keeps the track of active childs (usually I spawn like 250 of them) and distributes the incoming requests. As far as I understand each child operates on its own. rr -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Syntactic improvement to array
On Tue, February 6, 2007 11:26 am, Andrei Zmievski wrote: On Feb 5, 2007, at 3:37 PM, Richard Lynch wrote: Yes, and it makes life miserable for some of us... Is that a good reason to extend that misery to yet another operator? Richard, please. This is not advanced OO stuff or anything close. It's an operator. Give PHP users (even newbies) some credit. I was specifically thinking of the sheer number of emails to PHP-General that would result. Even if 90% of the newbies get it without any research, and 5% more figure it out from context or reading or trying, there's still a heck of a lot who will end up posting. -- Some people have a gift link here. Know what I want? I want you to buy a CD from some starving artist. http://cdbaby.com/browse/from/lynch Yeah, I get a buck. So? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Syntactic improvement to array
Actually, this one was prompted by seeing a bug fix or changelog about
requiring { } and : endif; to match up, rather than accepting
either/or in balance.
Synchronicity that I even saw that item, but there it is.
I would HOPE that they'd have to balance, but if they don't for the
long block syntax instead of braces, maybe they shouldn't.
Once you have two ways to delimit start and end, you ought to nail
down what does or doesn't work.
The Regex thing with and for start/end delimiters is also a
counter-example of what other people seem to like.
I prefer not to take things for granted when defining new syntax,
personally.
On Tue, February 6, 2007 11:28 am, Andrei Zmievski wrote:
Now you're just grandstanding.
-Andrei
On Feb 5, 2007, at 3:55 PM, Richard Lynch wrote:
More edge cases:
$foo = array(1, 2, 3];
$bar = [1, 2, 3);
Syntax error because it's unbalancedO
Or kosher, because the choice of start/end delimiters should be up
to
the user?
Should it match whatever rule is in place for:
if (...){
endif;
--
Some people have a gift link here.
Know what I want?
I want you to buy a CD from some starving artist.
http://cdbaby.com/browse/from/lynch
Yeah, I get a buck. So?
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
Some people have a gift link here.
Know what I want?
I want you to buy a CD from some starving artist.
http://cdbaby.com/browse/from/lynch
Yeah, I get a buck. So?
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RE : [PHP-DEV] Re: Syntactic improvement to array
On Tue, February 6, 2007 8:17 am, LAUPRETRE François (P) wrote: From: Richard Lynch How many newbies will be trying: array[1, 2, 3]; and left scratching their heads when it doesn't work? Yes, even if I am in favor of the [] syntax, it is a good argument: 'array[ 1, 2, 3]' can become a very common error, and not especially among newbies! Maybe I am wrong, but would it be possible to accept all these syntaxes : array(1, 2, 3) (RHS only) [ 1, 2, 3 ] (RHS=array / LHS=list, I especially like: '$x = [ $a, $b ] = f()' :) list($a, $b)(LHS only) array[1, 2, 3] (RHS only) For this purpose, we could say that the [] notation is optionally preceded by 'array'. Another idea if you want to make it easier to understand for newbies: make array() and list() synonyms, so that array() behaves as list() when LHS, and list() behaves as array() when RHS. IMHO, it would become simpler to explain. If we implement both, we can even suppport 'list[ 1, 2, 3 ]'. How can we be more permissive? I probably needn't even post this, but: -1 Having even more ways to do everything is just confusing, not handy. -- Some people have a gift link here. Know what I want? I want you to buy a CD from some starving artist. http://cdbaby.com/browse/from/lynch Yeah, I get a buck. So? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] mod_fast_apache, FastCGI, and mysqli
From my experience with PHP over the years, in setups with both low and high traffic, I'd like to humbly put out a suggestion: have PHP include its own FastCGI SAPI in PHP 5.x and make it the default/recommended in PHP 6. Oh, and allow persistent connections in db apis again (like mysqli). The current FastCGI implementation for Apache has not changed in years (it actually won't compile on the Apache Group's recommended 2.2 version of Apache without end user tweaks). The code is there and it works, though I'm not sure of license compatibility. Though someone must know the protocol well since the PHP side of things was rewritten not long ago. Here are some of the benefits (and some rehash of things for the benefit of people finding this post via Google, et al): 1. FastCGI can be found across almost all web servers, and it factors out the whole threading issue. Threaded web servers can be a great benefit (and the event MPM in Apache 2.2 is a boon to using keep-alive efficiently). 2. In a process based webserver with PHP builtin as a module, every request has the whole php engine there -- even if it is not used (say a static image request, or just hanging around because of a keep-alive request). Each of those processes each hold to their persistent connections for, say, mysql. Which is why its such a bad thing -- all these processes holding open connections even if they aren't going to use them (like the image or keep-alive connection). Its around this point that we start thinking about connection pooling even though that is not needed. As an example, lets suppose an example with 2000 connections, using keep-alive, with 20 connections downloading static content and 50 downloading dynamic (PHP) content. In Apache 1.3, you would have to accommodate 2000 processes (either changing the hard limit, or using multiple servers). If you used persistent connections that would be 2000 (almost all idle) connections to mysql. (In the real world this is why you would either disable persistent connections or keep-alive, and most likely both.) Now in a Apache 2.0 and FastCGI context (out the hat, say 200 threads per process) we would have 10 processes to split the 2000 threads. Lets say you were wonderful at guessing the size of the PHP FastCGI pool and put it at 50 (same as the number of dynamic requests at this moment in time). You would have 50 connections to mysql as well (moving to fast-cgi really helped here!). In Apache 2.2 with event MPM, we would have one process and 200 threads (with only 71 being in active use). Same PHP process count as Apache 2.0 and same connection count to MySQL. Notice that the PHP FastCGI pool is acting as connection pooling rather effectively for persistent connections. You might have turned that off before, but now you can turn it on and see some return. 3. mysqli: OK, other than the fact that the FastCGI doesn't come preinstalled with either Apache or PHP, and you might have to tweak it to compile for Apache 2.2, you can do the above already today. So why this note? Well, if PHP told everyone via the manual and by integrating a fastcgi module (say mod_fast_apache, mod_fast_apache2, etc), then there likely (ok, hopefully) would have been some positive side effects. Like mysqli having persistent connections. I'm guessing they aren't there because people wanted to protect users from using them with a process based webserver like Apache1.3. Dumb users, it doesn't help them, only makes it worse. Yes, true, assuming people using mod_apache. Change the assumption, and maybe different things happen. Hmm, this is a lot to write when I could have said give us back persistent connections!... 4. Setting up FastCGI is horrible/ugly. Creating a fastcgi module for apache that only deals with PHP on the other end, gives a bit of leeway on how to do configuration stuff. Perhaps make FastCGi-PHP as easy to config as mod_apache. Thus calling it mod_fast_apache. People will be drawn to the word fast, btw :p 5. FastCGI is a far better base from which to deal with security for PHP, even if not addressed by PHP. Jails, having different processes for different users, etc. The latter doesn't interest me at all, but the former does. It need not be a security play, but it would give a better base from which to start. Well, my opinion, anyway. 6. I preface this with I don't know what I'm talking about here: is all the thread safe code in php really necessary? My experience is that FastCGI is both more stable and faster. Is php used in embedded threaded environments? Or was the the threading just for use on Windows, where we can better use FastCGI? Is there something to be gained by removing it? OMG, am I still writing? Somewhat off topic: Having the webserver and php run on the same machine is rather a poor mans way of scaling. Does anyone have stats on how well chained processing compares? (Like separating the web server and the PHP onto separate machines, or setup with a proxy server that
Re: [PHP-DEV] mod_fast_apache, FastCGI, and mysqli
steve wrote: Oh, and allow persistent connections in db apis again (like mysqli). It might happen. Wez Furlong was contemplating a persistent connection implementation for the generic PDO interface following on from the persistent connection model in the oci8 extension for Oracle. As an example, lets suppose an example with 2000 connections, using keep-alive, with 20 connections downloading static content and 50 downloading dynamic (PHP) content. In Apache 1.3, you would have to accommodate 2000 processes (either changing the hard limit, or using multiple servers). If you used persistent connections that would be 2000 (almost all idle) connections to mysql. (In the real world this is why you would either disable persistent connections or keep-alive, and most likely both.) The oci8 extension lets you timeout idle persistent connections. Unrelated to your FastCGI suggestion but FYI on database connection pooling: http://blogs.oracle.com/opal/2007/01/03. The pooling described has no dependency on how you deploy your application and works across multiple application types connecting to the DB. Chris -- Christopher Jones, Oracle Email: [EMAIL PROTECTED]Tel: +1 650 506 8630 Blog: http://blogs.oracle.com/opal/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Known Issues with PHP6 on Windows?
Hey everyone, I was just curious if there were any known issues with the PHP6 builds on Windows. I've been trying to set a build up in my local environment and Apache keeps throwing this error at me: Syntax error on line 173 of C:/Apache2/conf/httpd.conf: Can't locate API module structure `php6_module' in file C:/php6/php6apache2.dll: No error Thanks. -- Jeremy C. Privett Chief Operating Officer Zend Certified Engineer Completely Unique [EMAIL PROTECTED] Phone: 303.459.4819 Mobile:303.883.0312 Fax: 303.459.4821 Web: www.completelyunique.com This email may contain confidential and privileged material for the sole use of the intended recipient. Any review or distribution by others is strictly prohibited. If you are not the intended recipient please contact the sender and delete all copies. Your compliance is appreciated. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] [PATCH] better implementation for __HALT_COMPILER();
Hi,
With the first release of pecl/phar, I have started thinking about the
implementation of __HALT_COMPILER();
Currently, this code results in a fatal error:
file1.php:
?php
__HALT_COMPILER();
?
file2.php:
?php
__HALT_COMPILER();
?
file3.php:
?php
include 'file1.php';
include 'file2.php'; // fatal error - can't declare __HALT_COMPILER();
more than once in the same request
?
The current implementation simply defines __COMPILER_HALT_OFFSET__ as
the first __HALT_COMPILER();, independent of the file.
However, it occurred to me that it might be easy to fix this by
introducing a hash of halt offsets by file. After talking to Sara on
IRC, she proved she is truly an internals goddess by suggesting instead
to use a mangled constant name (__COMPILER_HALT_OFFSET__ + filename) and
use the existing global constants hash instead. So, with that helpful
tip, I whipped up a patch to provide file-specific
__COMPILER_HALT_OFFSET__. This does change behavior in that
__COMPILER_HALT_OFFSET__ can only be used within the same file that it
is defined. However, this is extremely unlikely to break any existing
scripts since it was designed for self-contained installers, and to my
knowledge, Phar/PHP_Archive and some auxiliary thing called PHK are the
only things using it. The benefits to users of phar-like things would
be immense, with no performance degradation for anything except for the
worst case constant lookup where a user requests the value of an
undefined constant (UPPERCASE constant doesn't exist, lowercase constant
doesn't exist).
Anyways, the patch is very short, so I've attached it. This patch is
against PHP_5_2 (since I consider it a bug fix) and I will happily whip
up a patch against HEAD if it is acceptable. My assumption here, of
course, is that this would go in 5.2.2 at the earliest since Ilia was
waiting for a CVS lock to release in order to put up 5.2.1 while I was
coding the patch.
Thanks,
Greg
? better_halt.patch.txt
? zlib.patch
? ext/zlib/zlib_filter.c.2
? pear/scripts
Index: Zend/zend_compile.c
===
RCS file: /repository/ZendEngine2/zend_compile.c,v
retrieving revision 1.647.2.27.2.29
diff -u -r1.647.2.27.2.29 zend_compile.c
--- Zend/zend_compile.c 1 Feb 2007 15:23:46 - 1.647.2.27.2.29
+++ Zend/zend_compile.c 7 Feb 2007 05:41:45 -
@@ -3094,7 +3094,18 @@
zend_llist_add_element(fetch_list_ptr, opline);
}
-
+void zend_do_halt_compiler_register(TSRMLS_D)
+{
+ char *name, *cfilename;
+ char haltoff[] = __COMPILER_HALT_OFFSET__;
+ int len, clen;
+ cfilename = zend_get_compiled_filename(TSRMLS_C);
+ clen = strlen(cfilename);
+ zend_mangle_property_name(name, len, haltoff,
+ sizeof(__COMPILER_HALT_OFFSET__) - 1, cfilename, clen, 0);
+ zend_register_long_constant(name, len+1,
zend_get_scanned_file_offset(TSRMLS_C), CONST_CS, 0 TSRMLS_CC);
+ pefree(name, 0);
+}
void zend_do_declare_implicit_property(TSRMLS_D)
{
Index: Zend/zend_compile.h
===
RCS file: /repository/ZendEngine2/zend_compile.h,v
retrieving revision 1.316.2.8.2.9
diff -u -r1.316.2.8.2.9 zend_compile.h
--- Zend/zend_compile.h 10 Jan 2007 15:58:07 - 1.316.2.8.2.9
+++ Zend/zend_compile.h 7 Feb 2007 05:41:46 -
@@ -447,6 +447,7 @@
void zend_do_fetch_property(znode *result, znode *object, znode *property
TSRMLS_DC);
+void zend_do_halt_compiler_register(TSRMLS_D);
void zend_do_push_object(znode *object TSRMLS_DC);
void zend_do_pop_object(znode *object TSRMLS_DC);
Index: Zend/zend_constants.c
===
RCS file: /repository/ZendEngine2/zend_constants.c,v
retrieving revision 1.71.2.5.2.4
diff -u -r1.71.2.5.2.4 zend_constants.c
--- Zend/zend_constants.c 1 Jan 2007 09:35:46 - 1.71.2.5.2.4
+++ Zend/zend_constants.c 7 Feb 2007 05:41:46 -
@@ -277,7 +277,7 @@
return retval;
}
-
+
if (zend_hash_find(EG(zend_constants), name, name_len+1, (void **) c)
== FAILURE) {
lookup_name = estrndup(name, name_len);
zend_str_tolower(lookup_name, name_len);
@@ -287,7 +287,26 @@
retval=0;
}
} else {
- retval=0;
+ char haltoff[] = __COMPILER_HALT_OFFSET__;
+ if (!EG(in_execution)) {
+ retval = 0;
+ } else if (name_len ==
sizeof(__COMPILER_HALT_OFFSET__) - 1 memcmp(haltoff, name, name_len) == 0)
{
+ char *cfilename, *haltname;
+ int len, clen;
+ cfilename =
zend_get_executed_filename(TSRMLS_C);
+ clen = strlen(cfilename);
+ /*
[PHP-DEV] Re: [PATCH] better implementation for __HALT_COMPILER();
Gregory Beaver wrote: __COMPILER_HALT_OFFSET__. This does change behavior in that __COMPILER_HALT_OFFSET__ can only be used within the same file that it is defined. However, this is extremely unlikely to break any existing scripts since it was designed for self-contained installers, and to my knowledge, Phar/PHP_Archive and some auxiliary thing called PHK are the only things using it. The benefits to users of phar-like things would I meant to say only other things using it with the primary usage being FUDForum and other single-file installers that have no need to support multiple __HALT_COMPILER();. Greg -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] mod_fast_apache, FastCGI, and mysqli
Christopher Jones wrote: steve wrote: Oh, and allow persistent connections in db apis again (like mysqli). It might happen. Wez Furlong was contemplating a persistent connection implementation for the generic PDO interface following on from the persistent connection model in the oci8 extension for Oracle. I guess MySQL folks are also looking into Java like connection pooling: http://krow.livejournal.com/487174.html regards, Lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] mod_fast_apache, FastCGI, and mysqli
A couple of points. mysqli doesn't have persistent connections because the authors of that particular extension don't think it is a good idea. It's not a PHP-wide thing, PDO and others do have it. If you are going to FastCGI for performance and scalability reasons because you don't want a heavyweight web server process handle a dynamic request, then you are essentially just using the web server as a proxy which isn't really what it was written to be. There are much more effective reverse proxies out there that can do that. The best reason for FastCGI, and why you won't find anyone saying it is a bad thing to support, is for shared hosting services to better separate users in system-level jails. Let's not get carried away and make it out to be the solution to everything, because it certainly isn't. The larger companies have Akamai or Akamai-like solutions for all their static file needs, and most of the smaller ones have thttpd or lighhttpd lightweight servers handling those or they have stuck Squid or Pound out in front. For these sorts of architectures the extra handoff to a FastCGI process doesn't make much sense because every request that gets through to the web server is going to be a dynamic one so Apache1 or Apache2-prefork is managing these process-based PHP interpreters in exactly the same fashion that FastCGI would with the exception that you have more control with the richness of Apache and you are closer to the actual request and can make use of the rich set of Apache modules out there. So yes, for the ISP case, I am all for suggesting that FastCGI should be the default way to run PHP. We've been saying that for a while actually. But in other cases you are going to have a much harder time convincing me. And I actually know a little bit about running PHP in extremely high-traffic situations. -Rasmus steve wrote: From my experience with PHP over the years, in setups with both low and high traffic, I'd like to humbly put out a suggestion: have PHP include its own FastCGI SAPI in PHP 5.x and make it the default/recommended in PHP 6. Oh, and allow persistent connections in db apis again (like mysqli). The current FastCGI implementation for Apache has not changed in years (it actually won't compile on the Apache Group's recommended 2.2 version of Apache without end user tweaks). The code is there and it works, though I'm not sure of license compatibility. Though someone must know the protocol well since the PHP side of things was rewritten not long ago. Here are some of the benefits (and some rehash of things for the benefit of people finding this post via Google, et al): 1. FastCGI can be found across almost all web servers, and it factors out the whole threading issue. Threaded web servers can be a great benefit (and the event MPM in Apache 2.2 is a boon to using keep-alive efficiently). 2. In a process based webserver with PHP builtin as a module, every request has the whole php engine there -- even if it is not used (say a static image request, or just hanging around because of a keep-alive request). Each of those processes each hold to their persistent connections for, say, mysql. Which is why its such a bad thing -- all these processes holding open connections even if they aren't going to use them (like the image or keep-alive connection). Its around this point that we start thinking about connection pooling even though that is not needed. As an example, lets suppose an example with 2000 connections, using keep-alive, with 20 connections downloading static content and 50 downloading dynamic (PHP) content. In Apache 1.3, you would have to accommodate 2000 processes (either changing the hard limit, or using multiple servers). If you used persistent connections that would be 2000 (almost all idle) connections to mysql. (In the real world this is why you would either disable persistent connections or keep-alive, and most likely both.) Now in a Apache 2.0 and FastCGI context (out the hat, say 200 threads per process) we would have 10 processes to split the 2000 threads. Lets say you were wonderful at guessing the size of the PHP FastCGI pool and put it at 50 (same as the number of dynamic requests at this moment in time). You would have 50 connections to mysql as well (moving to fast-cgi really helped here!). In Apache 2.2 with event MPM, we would have one process and 200 threads (with only 71 being in active use). Same PHP process count as Apache 2.0 and same connection count to MySQL. Notice that the PHP FastCGI pool is acting as connection pooling rather effectively for persistent connections. You might have turned that off before, but now you can turn it on and see some return. 3. mysqli: OK, other than the fact that the FastCGI doesn't come preinstalled with either Apache or PHP, and you might have to tweak it to compile for Apache 2.2, you can do the above already today. So why this note? Well, if PHP told
