[PHP-DEV] pecl, zts, non-zts, fastcgi and Apache

I'm building a script that installs PHP 5.3.10 from source. One of the
steps is to install apc and mongo support via pecl. I'm building the
CGI/FastCGI version. This is on a box that formerly had mod_php
installed.

If I do 'make install' of PHP (which installs a new pecl binary) and
follow it up immediately with 'pecl install apc', the apc extension
winds up here:

/usr/local/lib/php/extensions/no-debug-zts-20090626

That's not what command line php and php-cgi are looking for, so they
produce warnings and don't load the extensions.

However If I do the pecl install later - possibly after restarting
Apache with fastcgi enabled - it installs to the new, correct place:

no-debug-non-zts-20090626

The warnings go away, and everything is great.

This raises two questions about which no documentation seems to exist
after quite a bit of searching and which raise questions about whether
PHP is doing sensible things, so I took the liberty of bringing them
to folks who actually understand PHP's internals.

1. You only get one pecl binary although you may have many SAPIs
installed. mod_php defaults to thread-safe (and there seems to be no
way to turn that off on Linux), while php-cgi does not. So how does
pecl decide which way to build extensions? I tried setting
extensions_dir via config-set, but that setting was ignored (unless
perhaps it falls back if the folder doesn't exist yet?). How can I
ensure that, having just installed PHP and pecl, my next pecl install
will build extensions for the right flavor of PHP?

2. Why does php turn on thread-safety for mod_php at all on Linux,
given that it apparently still doesn't work very well with various
extensions in a genuinely multithreaded situation, slows things down,
takes more memory, and leads to problems like this one?

Everyone I've found runs PHP under the Apache prefork MPM, which does
not attempt to run PHP in multiple threads of one process. I have
never seen anyone successfully use the worker MPM with PHP, except by
moving PHP out to a fastcgi process pool, which is, again,
single-process PHP.

Even Microsoft's PHP accelerator uses the fastcgi-based,
one-process-per-PHP-request approach. Since Windows is so
thread-oriented that seems significant.

I have attached my script.

Thanks for any insight!

On Sun, Feb 5, 2012 at 9:59 AM, Nikita Popov <[email protected]> wrote:
> Hi internals!
>
> I have written an RFC that proposes to *deprecate* and *remove* the /e modifier:
>
> https://wiki.php.net/rfc/remove_preg_replace_eval_modifier
>
> Comments welcome!
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>



--
Tom Boutell
P'unk Avenue
215 755 1330
punkave.com
window.punkave.com
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

As far as Windows is concerned, it is worth noting that the Apache mod_php
(i.e. ZTS) build is supported. Also, though my information is a bit
outdated, last I heard work was being done to support thread-safe PHP as an
ISAPI module on IIS, though I don't know what the status of that is.

--Kris


On Fri, Feb 24, 2012 at 11:52 AM, Tom Boutell <[email protected]> wrote:

> I'm building a script that installs PHP 5.3.10 from source. One of the
> steps is to install apc and mongo support via pecl. I'm building the
> CGI/FastCGI version. This is on a box that formerly had mod_php
> installed.
>
> If I do 'make install' of PHP (which installs a new pecl binary) and
> follow it up immediately with 'pecl install apc', the apc extension
> winds up here:
>
> /usr/local/lib/php/extensions/no-debug-zts-20090626
>
> That's not what command line php and php-cgi are looking for, so they
> produce warnings and don't load the extensions.
>
> However If I do the pecl install later - possibly after restarting
> Apache with fastcgi enabled - it installs to the new, correct place:
>
> no-debug-non-zts-20090626
>
> The warnings go away, and everything is great.
>
> This raises two questions about which no documentation seems to exist
> after quite a bit of searching and which raise questions about whether
> PHP is doing sensible things, so I took the liberty of bringing them
> to folks who actually understand PHP's internals.
>
> 1. You only get one pecl binary although you may have many SAPIs
> installed. mod_php defaults to thread-safe (and there seems to be no
> way to turn that off on Linux), while php-cgi does not. So how does
> pecl decide which way to build extensions? I tried setting
> extensions_dir via config-set, but that setting was ignored (unless
> perhaps it falls back if the folder doesn't exist yet?). How can I
> ensure that, having just installed PHP and pecl, my next pecl install
> will build extensions for the right flavor of PHP?
>
> 2. Why does php turn on thread-safety for mod_php at all on Linux,
> given that it apparently still doesn't work very well with various
> extensions in a genuinely multithreaded situation, slows things down,
> takes more memory, and leads to problems like this one?
>
> Everyone I've found runs PHP under the Apache prefork MPM, which does
> not attempt to run PHP in multiple threads of one process. I have
> never seen anyone successfully use the worker MPM with PHP, except by
> moving PHP out to a fastcgi process pool, which is, again,
> single-process PHP.
>
> Even Microsoft's PHP accelerator uses the fastcgi-based,
> one-process-per-PHP-request approach. Since Windows is so
> thread-oriented that seems significant.
>
> I have attached my script.
>
> Thanks for any insight!
>
> On Sun, Feb 5, 2012 at 9:59 AM, Nikita Popov <[email protected]>
> wrote:
> > Hi internals!
> >
> > I have written an RFC that proposes to *deprecate* and *remove* the /e
> modifier:
> >
> > https://wiki.php.net/rfc/remove_preg_replace_eval_modifier
> >
> > Comments welcome!
> >
> > --
> > PHP Internals - PHP Runtime Development Mailing List
> > To unsubscribe, visit: http://www.php.net/unsub.php
> >
>
>
>
> --
> Tom Boutell
> P'unk Avenue
> 215 755 1330
> punkave.com
> window.punkave.com
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>

Good point. Last I tried that it worked poorly - I couldn't find a
bytecode cache that worked with it, performance was poor - and I
switched to the Microsoft accelerator and IIS. But things may have
changed.

Doesn't really explain it on Linux...

But what I really want to know is just how to get predictable behavior
in my script - after installing a new PHP and pecl I should be able to
do pecl installs and have them show up in the right extensions folder
for the PHP I just built, but no such luck.

(Yes, /usr/local/bin/pecl is the one I just built.)

On Fri, Feb 24, 2012 at 3:08 PM, Kris Craig <[email protected]> wrote:
> As far as Windows is concerned, it is worth noting that the Apache mod_php
> (i.e. ZTS) build is supported.  Also, though my information is a bit
> outdated, last I heard work was being done to support thread-safe PHP as an
> ISAPI module on IIS, though I don't know what the status of that is.
>
> --Kris
>
>
>
> On Fri, Feb 24, 2012 at 11:52 AM, Tom Boutell <[email protected]> wrote:
>>
>> I'm building a script that installs PHP 5.3.10 from source. One of the
>> steps is to install apc and mongo support via pecl. I'm building the
>> CGI/FastCGI version. This is on a box that formerly had mod_php
>> installed.
>>
>> If I do 'make install' of PHP (which installs a new pecl binary) and
>> follow it up immediately with 'pecl install apc', the apc extension
>> winds up here:
>>
>> /usr/local/lib/php/extensions/no-debug-zts-20090626
>>
>> That's not what command line php and php-cgi are looking for, so they
>> produce warnings and don't load the extensions.
>>
>> However If I do the pecl install later - possibly after restarting
>> Apache with fastcgi enabled - it installs to the new, correct place:
>>
>> no-debug-non-zts-20090626
>>
>> The warnings go away, and everything is great.
>>
>> This raises two questions about which no documentation seems to exist
>> after quite a bit of searching and which raise questions about whether
>> PHP is doing sensible things, so I took the liberty of bringing them
>> to folks who actually understand PHP's internals.
>>
>> 1. You only get one pecl binary although you may have many SAPIs
>> installed. mod_php defaults to thread-safe (and there seems to be no
>> way to turn that off on Linux), while php-cgi does not. So how does
>> pecl decide which way to build extensions? I tried setting
>> extensions_dir via config-set, but that setting was ignored (unless
>> perhaps it falls back if the folder doesn't exist yet?). How can I
>> ensure that, having just installed PHP and pecl, my next pecl install
>> will build extensions for the right flavor of PHP?
>>
>> 2. Why does php turn on thread-safety for mod_php at all on Linux,
>> given that it apparently still doesn't work very well with various
>> extensions in a genuinely multithreaded situation, slows things down,
>> takes more memory, and leads to problems like this one?
>>
>> Everyone I've found runs PHP under the Apache prefork MPM, which does
>> not attempt to run PHP in multiple threads of one process. I have
>> never seen anyone successfully use the worker MPM with PHP, except by
>> moving PHP out to a fastcgi process pool, which is, again,
>> single-process PHP.
>>
>> Even Microsoft's PHP accelerator uses the fastcgi-based,
>> one-process-per-PHP-request approach. Since Windows is so
>> thread-oriented that seems significant.
>>
>> I have attached my script.
>>
>> Thanks for any insight!
>>
>> On Sun, Feb 5, 2012 at 9:59 AM, Nikita Popov <[email protected]>
>> wrote:
>> > Hi internals!
>> >
>> > I have written an RFC that proposes to *deprecate* and *remove* the /e
>> > modifier:
>> >
>> > https://wiki.php.net/rfc/remove_preg_replace_eval_modifier
>> >
>> > Comments welcome!
>> >
>> > --
>> > PHP Internals - PHP Runtime Development Mailing List
>> > To unsubscribe, visit: http://www.php.net/unsub.php
>> >
>>
>>
>>
>> --
>> Tom Boutell
>> P'unk Avenue
>> 215 755 1330
>> punkave.com
>> window.punkave.com
>>
>> --
>> PHP Internals - PHP Runtime Development Mailing List
>> To unsubscribe, visit: http://www.php.net/unsub.php
>
>



--
Tom Boutell
P'unk Avenue
215 755 1330
punkave.com
window.punkave.com

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

hi,

On Fri, Feb 24, 2012 at 9:30 PM, Tom Boutell <[email protected]> wrote:
> Good point. Last I tried that it worked poorly - I couldn't find a
> bytecode cache that worked with it, performance was poor - and I
> switched to the Microsoft accelerator and IIS. But things may have
> changed.


APC with rwlock is faster than before under Apache:

http://www.php.net/~pierre/vcqa/apcigninary_perf.png
http://www.php.net/~pierre/vcqa/apc-rwlock-win.pdf

And that was possible only by doing changes in APC only.


Microsoft has no policy or whatever else when it comes to PHP but they
support FastCGI because it was easier for the IIS team to develop
FastCGI support for IIS than trying to get support via ISAPI for all
other languages. But it is imo a bad design solution (long term),
while working very so far.

PHP on windows supports both NTS and TS (Apache) and will certainly
support again TS under IIS again in PHP next.

> Doesn't really explain it on Linux...
>
> But what I really want to know is just how to get predictable behavior
> in my script - after installing a new PHP and pecl I should be able to
> do pecl installs and have them show up in the right extensions folder
> for the PHP I just built, but no such luck.

that's why php-config exists, use it to get which version of PHP is
installed or has to be used (nts, ts, php version, api version, etc.).
That's all parameter you need to know. php-config should give you the
path as well afair.

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

On Fri, Feb 24, 2012 at 3:47 PM, Pierre Joye <[email protected]> wrote:
>
> that's why php-config exists, use it to get which version of PHP is
> installed or has to be used (nts, ts, php version, api version, etc.).
> That's all parameter you need to know. php-config should give you the
> path as well afair.

Then shouldn't a 'make install' of PHP have changed php-config on the
spot? Why wouldn't the pecl install I do immediately after that be
aware of the changes? The delay is what's puzzling. What good does it
do me to look at php-config output if pecl doesn't seem to?

--
Tom Boutell
P'unk Avenue
215 755 1330
punkave.com
window.punkave.com

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Once a package has been fetched, pecl install does nothing else than:

phpize, make, make install

and phpize does use php-config.


On Fri, Feb 24, 2012 at 9:51 PM, Tom Boutell <[email protected]> wrote:
> On Fri, Feb 24, 2012 at 3:47 PM, Pierre Joye <[email protected]> wrote:
>>
>> that's why php-config exists, use it to get which version of PHP is
>> installed or has to be used (nts, ts, php version, api version, etc.).
>> That's all parameter you need to know. php-config should give you the
>> path as well afair.
>
> Then shouldn't a 'make install' of PHP have changed php-config on the
> spot? Why wouldn't the pecl install I do immediately after that be
> aware of the changes? The delay is what's puzzling. What good does it
> do me to look at php-config output if pecl doesn't seem to?
>
> --
> Tom Boutell
> P'unk Avenue
> 215 755 1330
> punkave.com
> window.punkave.com



--
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

On Fri, February 24, 2012 1:52 pm, Tom Boutell wrote:
> 2. Why does php turn on thread-safety for mod_php at all on Linux,
> given that it apparently still doesn't work very well with various
> extensions in a genuinely multithreaded situation, slows things down,
> takes more memory, and leads to problems like this one?

I can't recall who, but I have heard people who claim to run
multi-threaded on Linux, but with a heck of a lot of stress testing,
and a rigid control on minimal extensions added...

So apparently *somebody* uses it.

--
brain cancer update:
http://richardlynch.blogspot.com/search/label/brain%20tumor
Donate:
https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclick&hosted_button_id=FS9NLTNEEKWBE



--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

PHP through mod_php on Linux should compile without ZTS.

configure script searches for apxs binary and tries to invoque "apxs -q
MPM" to figure out what MPM has been compiled in Apache for the TS flag to
be defined or not (thus, activating PHP ZTS, or not).

Mainly on Linux, Apache should have been installed with prefork MPM ans
"apxs -q" should return that, then configure should not define
PHP_BUILD_THREAD_SAFE.

Recently we had a bug with the new Apache 2.4 API where apxs doesn't answer
about the MPM configuration anymore, leading to a ZTS build by default.
This bug has now been fixed, was https://bugs.php.net/bug.php?id=61172.

I dont know anything about windows, sorry

Julien.Pauli

On Fri, Feb 24, 2012 at 10:04 PM, Richard Lynch <[email protected]> wrote:

> On Fri, February 24, 2012 1:52 pm, Tom Boutell wrote:
> > 2. Why does php turn on thread-safety for mod_php at all on Linux,
> > given that it apparently still doesn't work very well with various
> > extensions in a genuinely multithreaded situation, slows things down,
> > takes more memory, and leads to problems like this one?
>
> I can't recall who, but I have heard people who claim to run
> multi-threaded on Linux, but with a heck of a lot of stress testing,
> and a rigid control on minimal extensions added...
>
> So apparently *somebody* uses it.
>
> --
> brain cancer update:
> http://richardlynch.blogspot.com/search/label/brain%20tumor
> Donate:
>
> https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclick&hosted_button_id=FS9NLTNEEKWBE
>
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

On 2/27/2012 6:58 AM, jpauli wrote:
> PHP through mod_php on Linux should compile without ZTS.
>
> configure script searches for apxs binary and tries to invoque "apxs -q
> MPM" to figure out what MPM has been compiled in Apache for the TS flag to
> be defined or not (thus, activating PHP ZTS, or not).

Right...

> Mainly on Linux, Apache should have been installed with prefork MPM ans
> "apxs -q" should return that, then configure should not define
> PHP_BUILD_THREAD_SAFE.

No, 2.2 and 2.4 don't default to prefork, it's suboptimal, most linux
distros have moved away from it...

> Recently we had a bug with the new Apache 2.4 API where apxs doesn't answer
> about the MPM configuration anymore, leading to a ZTS build by default.
> This bug has now been fixed, was https://bugs.php.net/bug.php?id=61172.

Wrong fix. Out of the box you don't know which mpm may be loaded, because
the mpm is now loadable (although a full daemon stop/start is necessary).
The only mod_php loadable under any circumstance is TS enabled.

If you want php/linux single-child, fastcgi is the only rational approach.

> I dont know anything about windows, sorry

Always threaded.


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

On 02/27/2012 01:12 PM, William A. Rowe Jr. wrote:
> On 2/27/2012 6:58 AM, jpauli wrote:

>> Recently we had a bug with the new Apache 2.4 API where apxs doesn't answer
>> about the MPM configuration anymore, leading to a ZTS build by default.
>> This bug has now been fixed, was https://bugs.php.net/bug.php?id=61172.
>
> Wrong fix. Out of the box you don't know which mpm may be loaded, because
> the mpm is now loadable (although a full daemon stop/start is necessary).

Can you expand & explain this, with an eye to resolving 61172?
Are you saying Apache 2.4 'httpd -M' might not return the mpm?

> The only mod_php loadable under any circumstance is TS enabled.


Chris

--
Email: christopher.jones@oracle.com
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

On Mon, Feb 27, 2012 at 10:12 PM, William A. Rowe Jr.
<[email protected]>wrote:

> On 2/27/2012 6:58 AM, jpauli wrote:
> > PHP through mod_php on Linux should compile without ZTS.
> >
> > configure script searches for apxs binary and tries to invoque "apxs -q
> > MPM" to figure out what MPM has been compiled in Apache for the TS flag
> to
> > be defined or not (thus, activating PHP ZTS, or not).
>
> Right...
>
> > Mainly on Linux, Apache should have been installed with prefork MPM ans
> > "apxs -q" should return that, then configure should not define
> > PHP_BUILD_THREAD_SAFE.
>
> No, 2.2 and 2.4 don't default to prefork, it's suboptimal, most linux
> distros have moved away from it...
>
> Sorry but 2.2 defaults to prefork.
The new 2.4 platform has introduced loadable MPM, like any other module ,
thus we cant detect through
apxs which MPM is used anymore. For this, we would need to play with httpd
-M



> > Recently we had a bug with the new Apache 2.4 API where apxs doesn't
> answer
> > about the MPM configuration anymore, leading to a ZTS build by default.
> > This bug has now been fixed, was https://bugs.php.net/bug.php?id=61172.
>
> Wrong fix. Out of the box you don't know which mpm may be loaded, because
> the mpm is now loadable (although a full daemon stop/start is necessary).
> The only mod_php loadable under any circumstance is TS enabled.
>

Yes, but ZTS has a performance/memory penalty due to globals locks.
I would much prefer having a nonZTS PHP together with a non threaded MPM

Julien.P


> If you want php/linux single-child, fastcgi is the only rational approach.
>
> > I dont know anything about windows, sorry
>
> Always threaded.
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

PHP needs a lot more memory than, say, serving static files. If you
used PHP with the worker threaded MPM, and it worked (I haven't heard
many stories of people doing this under Linux), wouldn't you just have
to dial back the number of threads to pretty much the number of
processes you would have allowed under the prefork MPM? The overhead
of a process is pretty tiny next to the overhead of a PHP framework.

Aren't you therefore just paying a performance and stability price
(threadsafe is slower than non-threadsafe, your extensions may or may
not play nice...) for not a lot of benefit under Linux when PHP runs
under the worker threaded MPM?

The best configuration I'm aware of is to run Apache with the worker
threaded MPM, and run PHP in a fastcgi pool, so that you can have
hundreds of threads serving static and cached content in a hurry, and
a smaller pool of more expensive PHP processes. I'm interested to hear
if anyone feels there is a superior model for single-server PHP
hosting under Linux.

(I realize that static files could be pushed out to CDNs and the like
but our clients much prefer to have a single straightforward hosting
bill to pay, thus the single-server thing for most cases.)

On Tue, Feb 28, 2012 at 4:13 AM, jpauli <[email protected]> wrote:
> On Mon, Feb 27, 2012 at 10:12 PM, William A. Rowe Jr.
> <[email protected]>wrote:
>
>> On 2/27/2012 6:58 AM, jpauli wrote:
>> > PHP through mod_php on Linux should compile without ZTS.
>> >
>> > configure script searches for apxs binary and tries to invoque "apxs -q
>> > MPM" to figure out what MPM has been compiled in Apache for the TS flag
>> to
>> > be defined or not (thus, activating PHP ZTS, or not).
>>
>> Right...
>>
>> > Mainly on Linux, Apache should have been installed with prefork MPM ans
>> > "apxs -q" should return that, then configure should not define
>> > PHP_BUILD_THREAD_SAFE.
>>
>> No, 2.2 and 2.4 don't default to prefork, it's suboptimal, most linux
>> distros have moved away from it...
>>
>> Sorry but 2.2 defaults to prefork.
> The new 2.4 platform has introduced loadable MPM, like any other module ,
> thus we cant detect through
> apxs which MPM is used anymore. For this, we would need to play with httpd
> -M
>
>
>
>> > Recently we had a bug with the new Apache 2.4 API where apxs doesn't
>> answer
>> > about the MPM configuration anymore, leading to a ZTS build by default..
>> > This bug has now been fixed, was https://bugs.php.net/bug.php?id=61172.
>>
>> Wrong fix.  Out of the box you don't know which mpm may be loaded, because
>> the mpm is now loadable (although a full daemon stop/start is necessary)..
>> The only mod_php loadable under any circumstance is TS enabled.
>>
>
> Yes, but ZTS has a performance/memory penalty due to globals locks.
> I would much prefer having a nonZTS PHP together with a non threaded MPM
>
> Julien.P
>
>
>> If you want php/linux single-child, fastcgi is the only rational approach.
>>
>> > I dont know anything about windows, sorry
>>
>> Always threaded.
>>
>>
>> --
>> PHP Internals - PHP Runtime Development Mailing List
>> To unsubscribe, visit: http://www.php.net/unsub.php
>>
>>



--
Tom Boutell
P'unk Avenue
215 755 1330
punkave.com
window.punkave.com

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

On Mon, Feb 27, 2012 at 4:12 PM, William A. Rowe Jr.
<[email protected]> wrote:
>
> No, 2.2 and 2.4 don't default to prefork, it's suboptimal, most linux
> distros have moved away from it...

Ubuntu starts out with the worker threaded MPM. However when you
install the standard PHP package it switches Apache to the prefork
MPM.

--
Tom Boutell
P'unk Avenue
215 755 1330
punkave.com
window.punkave.com

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

On Tue, Feb 28, 2012 at 3:37 PM, Tom Boutell <[email protected]> wrote:

> On Mon, Feb 27, 2012 at 4:12 PM, William A. Rowe Jr.
> <[email protected]> wrote:
> >
> > No, 2.2 and 2.4 don't default to prefork, it's suboptimal, most linux
> > distros have moved away from it...
>
> Ubuntu starts out with the worker threaded MPM. However when you
> install the standard PHP package it switches Apache to the prefork
> MPM.
>
> Actually, the true story for performance is to kill Apache and let
Lighttpd or NginX do the job, with a pool of fcgi/fpm PHP processes

About having a ZTS mod_php inside a Worker-based Apache : I know Brian Moon
having tried that on a production host some time ago.
He shares experiences here :
http://doughboy.wordpress.com/2008/02/13/apache-worker-and-php/

Hope this helps, even if it is not a recommended architecture ;)

Julien.P



> --
> Tom Boutell
> P'unk Avenue
> 215 755 1330
> punkave.com
> window.punkave.com
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

On Mon, February 27, 2012 6:46 pm, Christopher Jones wrote:
>
>
> On 02/27/2012 01:12 PM, William A. Rowe Jr. wrote:
>> On 2/27/2012 6:58 AM, jpauli wrote:
>
>>> Recently we had a bug with the new Apache 2.4 API where apxs
>>> doesn't answer
>>> about the MPM configuration anymore, leading to a ZTS build by
>>> default.
>>> This bug has now been fixed, was
>>> https://bugs.php.net/bug.php?id=61172.
>>
>> Wrong fix. Out of the box you don't know which mpm may be loaded,
>> because
>> the mpm is now loadable (although a full daemon stop/start is
>> necessary).
>
> Can you expand & explain this, with an eye to resolving 61172?
> Are you saying Apache 2.4 'httpd -M' might not return the mpm?

If I'm reading this correctly:

apxs runs at PHP compile time and "reads" mpm from httpd.conf

Apache is started, probably with that mpm, and then a different mpm is
loaded and apache is re-started, maybe even with graceful, for real
fun.

mod_php has no knowledge of the "new" mpm, because the mpm choice was
compiled in at apxs time.

--
brain cancer update:
http://richardlynch.blogspot.com/search/label/brain%20tumor
Donate:
https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclick&hosted_button_id=FS9NLTNEEKWBE



--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

On Tue, Feb 28, 2012 at 10:41 AM, jpauli <[email protected]> wrote:

> Actually, the true story for performance is to kill Apache and let Lighttpd
> or NginX do the job, with a pool of fcgi/fpm PHP processes

I'd like to ask you whether it really makes much difference to use
Lighttpd or NginX as opposed to Apache with the worker thread MPM, but
at that point we are officially way off topic (:

I think that in terms of general architecture, and in terms of what to
do with PHP, those three options are basically the same option.

I haven't studied FPM yet as I haven't felt a need for its advertised
advantages over the traditional FastCGI support in the CGI SAPI yet.

I will check out the apache worker and PHP article, thanks.

--
Tom Boutell
P'unk Avenue
215 755 1330
punkave.com
window.punkave.com

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

I did check out the article on using worker thread MPM with PHP on
Linux. The basic argument is that since threads can reclaim memory
used and then freed by other PHP requests, while processes don't
return memory to the OS until they finally exit, there is more memory
available.

However I doubt that this can be the case when the server is at peak
utilization. When things are maxed out you will still have, say, 20
threads hitting PHP scripts that happen to be expensive in terms of
memory (let's say 50mb), and that will be roughly all the memory you
have to play with in your 1GB system.

So you're just as stuck as if you had 20 dedicated fastcgi processes,
all maxed out at 50mb already by some previous request.

The only win here is that in the average case, you can handle more
requests. But you usually can't predict in advance when the worst case
will come along. So if you permit that to happen you are risking a
slowdown or a meltdown (:

For stability a fastcgi pool of the size you know you can handle based
on studying your past memory stats still seems to be the way to go.

> On Tue, Feb 28, 2012 at 10:41 AM, jpauli <[email protected]> wrote:
>
>> Actually, the true story for performance is to kill Apache and let Lighttpd
>> or NginX do the job, with a pool of fcgi/fpm PHP processes
>
> I'd like to ask you whether it really makes much difference to use
> Lighttpd or NginX as opposed to Apache with the worker thread MPM, but
> at that point we are officially way off topic (:
>
> I think that in terms of general architecture, and in terms of what to
> do with PHP, those three options are basically the same option.
>
> I haven't studied FPM yet as I haven't felt a need for its advertised
> advantages over the traditional FastCGI support in the CGI SAPI yet.
>
> I will check out the apache worker and PHP article, thanks.
>
> --
> Tom Boutell
> P'unk Avenue
> 215 755 1330
> punkave.com
> window.punkave.com



--
Tom Boutell
P'unk Avenue
215 755 1330
punkave.com
window.punkave.com

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

On 2/27/2012 6:46 PM, Christopher Jones wrote:
>
> On 02/27/2012 01:12 PM, William A. Rowe Jr. wrote:
>> On 2/27/2012 6:58 AM, jpauli wrote:
>
>>> Recently we had a bug with the new Apache 2.4 API where apxs doesn't answer
>>> about the MPM configuration anymore, leading to a ZTS build by default.
>>> This bug has now been fixed, was https://bugs.php.net/bug.php?id=61172.
>>
>> Wrong fix. Out of the box you don't know which mpm may be loaded, because
>> the mpm is now loadable (although a full daemon stop/start is necessary).
>
> Can you expand & explain this, with an eye to resolving 61172?
> Are you saying Apache 2.4 'httpd -M' might not return the mpm?

The mpm is now a loadable module, not compiled in. The recommended default mpm
is now event, the recommended .rpm proposes shipping event/worker/prefork, all
as modules. The user is *free* to switch mpm's at any point by simply editing
their httpd.conf file, so what was a non-threaded server becomes a threaded one.

httpd -l will not return what you want, httpd -M will, but is not the right
solution...

# bin/httpd -l
Compiled in modules:
core.c
mod_so.c
http_core.c

# bin/httpd -M
Loaded Modules:
core_module (static)
so_module (static)
http_module (static)
....
version_module (shared)
mpm_event_module (shared)
unixd_module (shared)
....

The httpd -V command was always the correct way to test for threaded'ness,
which would allow supporting an mpm which was not known to you. Again, it
will only reflect the currently loaded module (and fail if no MPM is loaded);

# bin/httpd -V
Server version: Apache/2.4.1 (Unix)
Server built: Feb 28 2012 10:37:32
Server's Module Magic Number: 20120211:0
Server loaded: APR 1.4.5, APR-UTIL 1.3.12
Compiled using: APR 1.4.5, APR-UTIL 1.3.12
Architecture: 64-bit
Server MPM: event
threaded: yes (fixed thread count)
forked: yes (variable process count)
....

Editing httpd.conf... s/event/prefork/ results in
....
Server MPM: prefork
threaded: no
forked: yes (variable process count)

In 2.2 the default MPM became worker. In 2.4 the default MPM is now event,
so prefork hasn't been the default in some 7 years. The only sensible build
for mod_php is ZTS, which will load and operate whichever mpm is loaded by
the user. The only sensible single thread environment is cgi (enhanced,
of course, with fastcgi!)


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Hi!

> so prefork hasn't been the default in some 7 years. The only sensible build
> for mod_php is ZTS, which will load and operate whichever mpm is loaded by
> the user. The only sensible single thread environment is cgi (enhanced,
> of course, with fastcgi!)


Please note that TS build is slower and has higher memory requirements
(due to TS locks and TS data structures) so having it as only build may
not be optimal.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

On 02/28/2012 08:51 AM, William A. Rowe Jr. wrote:
> On 2/27/2012 6:46 PM, Christopher Jones wrote:
>>
>> On 02/27/2012 01:12 PM, William A. Rowe Jr. wrote:
>>> On 2/27/2012 6:58 AM, jpauli wrote:
>>
>>>> Recently we had a bug with the new Apache 2.4 API where apxs doesn't answer
>>>> about the MPM configuration anymore, leading to a ZTS build by default.
>>>> This bug has now been fixed, was https://bugs.php.net/bug.php?id=61172.
>>>
>>> Wrong fix. Out of the box you don't know which mpm may be loaded, because
>>> the mpm is now loadable (although a full daemon stop/start is necessary).
>>
>> Can you expand& explain this, with an eye to resolving 61172?
>> Are you saying Apache 2.4 'httpd -M' might not return the mpm?
>
> The mpm is now a loadable module, not compiled in. The recommended default mpm
> is now event, the recommended .rpm proposes shipping event/worker/prefork, all
> as modules. The user is *free* to switch mpm's at any point by simply editing
> their httpd.conf file, so what was a non-threaded server becomes a threaded one.
>
> httpd -l will not return what you want, httpd -M will, but is not the right
> solution...
>
> # bin/httpd -l
> Compiled in modules:
> core.c
> mod_so.c
> http_core.c
>
> # bin/httpd -M
> Loaded Modules:
> core_module (static)
> so_module (static)
> http_module (static)
> ...
> version_module (shared)
> mpm_event_module (shared)
> unixd_module (shared)
> ...
>
> The httpd -V command was always the correct way to test for threaded'ness,
> which would allow supporting an mpm which was not known to you. Again, it
> will only reflect the currently loaded module (and fail if no MPM is loaded);
>
> # bin/httpd -V
> Server version: Apache/2.4.1 (Unix)
> Server built: Feb 28 2012 10:37:32
> Server's Module Magic Number: 20120211:0
> Server loaded: APR 1.4.5, APR-UTIL 1.3.12
> Compiled using: APR 1.4.5, APR-UTIL 1.3.12
> Architecture: 64-bit
> Server MPM: event
> threaded: yes (fixed thread count)
> forked: yes (variable process count)
> ...
>
> Editing httpd.conf... s/event/prefork/ results in
> ...
> Server MPM: prefork
> threaded: no
> forked: yes (variable process count)
>
> In 2.2 the default MPM became worker. In 2.4 the default MPM is now event,
> so prefork hasn't been the default in some 7 years. The only sensible build
> for mod_php is ZTS, which will load and operate whichever mpm is loaded by
> the user. The only sensible single thread environment is cgi (enhanced,
> of course, with fastcgi!)
>

Thanks for clarifying that there is nothing unexpected (to me)
happening and for suggesting using -V.

It seems that the PHP installer could do one of two things:

1. Build PHP for the currently installed Apache MPM, using "httpd -V"
to identify whether to enable PHP's ZTS mode or not. PHP
documentation and/or 'configure' messages should state the MPM
shouldn't later be changed to threaded if it was originally
prefork. A proviso about ZTS overhead and limitations could be
noted.

2. Build PHP with ZTS enabled by default. Allow it to be explicitly
disabled during 'configure'

There are some variations of the above, depending on the target
audience(s) and scope of perceived problem.

Chris

--
Email: christopher.jones@oracle.com
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

On 02/28/2012 02:44 PM, Christopher Jones wrote:
> Build PHP with ZTS enabled by default. Allow it to be explicitly
> disabled during 'configure'

Why punish everyone by default because of Apache? Does not make sense to
me.

--
Sebastian Bergmann Co-Founder and Principal Consultant
http://sebastian-bergmann.de/ http://thePHP.cc/

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

I'm not sure I'd take it quite that far. I've done benchmarking of NTS and
ZTS builds and the difference really isn't anything I would consider worth
worrying about in most cases. It's fairly minor.

--Kris


On Tue, Feb 28, 2012 at 1:41 PM, Sebastian Bergmann <[email protected]>wrote:

> On 02/28/2012 02:44 PM, Christopher Jones wrote:
>
>> Build PHP with ZTS enabled by default. Allow it to be explicitly
>> disabled during 'configure'
>>
>
> Why punish everyone by default because of Apache? Does not make sense to
> me.
>
> --
> Sebastian Bergmann Co-Founder and Principal Consultant
> http://sebastian-bergmann.de/ http://thePHP.cc/
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Am 28.02.2012 22:41, schrieb Sebastian Bergmann:
> On 02/28/2012 02:44 PM, Christopher Jones wrote:
>> Build PHP with ZTS enabled by default. Allow it to be explicitly
>> disabled during 'configure'
>
> Why punish everyone by default because of Apache? Does not make sense to
> me.

even for apache it is a bad default
i bet the are more mod_php setups taht fast-cgi/cgi

On 2/28/2012 3:41 PM, Sebastian Bergmann wrote:
> On 02/28/2012 02:44 PM, Christopher Jones wrote:
>> Build PHP with ZTS enabled by default. Allow it to be explicitly
>> disabled during 'configure'
>
> Why punish everyone by default because of Apache? Does not make sense to
> me.

What is so difficult to grok about

1. setting up php-cgi to use fastcgi as the httpd default.

2. having parallel non-zts and zts installs of php (notably with only
non-zts cli and cgi sapi's) with two different lib paths. Multiply
by two again if you have parallel i686 and x86_64 installs.

All of these are packager's questions anyways, as so few users do this
for themself, most hosters aren't rebuilding php either.

PHP would be a much nicer, friendly and more civilized development list
if it borrowed only one phrase from the Perl community; TMTOWTDI.


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

On 02/28/2012 02:29 PM, William A. Rowe Jr. wrote:
> On 2/28/2012 3:41 PM, Sebastian Bergmann wrote:
>> On 02/28/2012 02:44 PM, Christopher Jones wrote:
>>> Build PHP with ZTS enabled by default. Allow it to be explicitly
>>> disabled during 'configure'
>>
>> Why punish everyone by default because of Apache? Does not make sense to
>> me.
>
> What is so difficult to grok about
>
> 1. setting up php-cgi to use fastcgi as the httpd default.
>
> 2. having parallel non-zts and zts installs of php (notably with only
> non-zts cli and cgi sapi's) with two different lib paths. Multiply
> by two again if you have parallel i686 and x86_64 installs.
>
> All of these are packager's questions anyways, as so few users do this
> for themself, most hosters aren't rebuilding php either.
>
> PHP would be a much nicer, friendly and more civilized development list
> if it borrowed only one phrase from the Perl community; TMTOWTDI.

These are useful suggestions for a future "bigger picture" direction
about sensible defaults, usability (or lack of), php-fpm, etc. This
is a problem looking for an owner.

In the narrow confines of https://bugs.php.net/bug.php?id=61172 the
packager has deliberately chosen to install mod_php. Like Sebastian,
I prefer that PHP configures itself for the currently installed Apache
MPM.

Chris

--
Email: christopher.jones@oracle.com
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

hi Bill,

On Tue, Feb 28, 2012 at 11:29 PM, William A. Rowe Jr.
<[email protected]> wrote:
> On 2/28/2012 3:41 PM, Sebastian Bergmann wrote:
>> On 02/28/2012 02:44 PM, Christopher Jones wrote:
>>> Build PHP with ZTS enabled by default. Allow it to be explicitly
>>> disabled during 'configure'
>>
>>  Why punish everyone by default because of Apache? Does not make sense to
>>  me.
>
> What is so difficult to grok about

Nothing, but it is easier to get a point when the rhetorical comments
are removed :)

>  1. setting up php-cgi to use fastcgi as the httpd default.
>
>  2. having parallel non-zts and zts installs of php (notably with only
>    non-zts cli and cgi sapi's) with two different lib paths.  Multiply
>    by two again if you have parallel i686 and x86_64 installs.
>
> All of these are packager's questions anyways, as so few users do this
> for themself, most hosters aren't rebuilding php either.

Right, and that's a rather big change, package wised. While the
lbraries (systems) are the same, at lest for 99.99% of them. There are
a few which can be built in TS or not TS mode but I don't think it is
worth it.

> PHP would be a much nicer, friendly and more civilized development list
> if it borrowed only one phrase from the Perl community; TMTOWTDI.

Civilized sounds very wrong in this context, or in general these days.

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

On Wed, Feb 29, 2012 at 9:18 AM, Pierre Joye <[email protected]> wrote:

> hi Bill,
>
> On Tue, Feb 28, 2012 at 11:29 PM, William A. Rowe Jr.
> <[email protected]> wrote:
> > On 2/28/2012 3:41 PM, Sebastian Bergmann wrote:
> >> On 02/28/2012 02:44 PM, Christopher Jones wrote:
> >>> Build PHP with ZTS enabled by default. Allow it to be explicitly
> >>> disabled during 'configure'
> >>
> >> Why punish everyone by default because of Apache? Does not make sense
> to
> >> me.
> >
> > What is so difficult to grok about
>
> Nothing, but it is easier to get a point when the rhetorical comments
> are removed :)
>
> > 1. setting up php-cgi to use fastcgi as the httpd default.
> >
> > 2. having parallel non-zts and zts installs of php (notably with only
> > non-zts cli and cgi sapi's) with two different lib paths. Multiply
> > by two again if you have parallel i686 and x86_64 installs.
> >
> > All of these are packager's questions anyways, as so few users do this
> > for themself, most hosters aren't rebuilding php either.
>
> Right, and that's a rather big change, package wised. While the
> lbraries (systems) are the same, at lest for 99.99% of them. There are
> a few which can be built in TS or not TS mode but I don't think it is
> worth it.
>
> > PHP would be a much nicer, friendly and more civilized development list
> > if it borrowed only one phrase from the Perl community; TMTOWTDI.
>
> Civilized sounds very wrong in this context, or in general these days.
>
> 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
>
>
Right, I suggest we leave #61172 as is, as it solves the problem.
PHP should be built with whatever MPM has been detected at configure time
(httpd -V) , and that's all.

The work of switching MPM later should be left to package maintainers, and
scripts like Debian's "a2enmod" which can handle that themselves.

Just my thoughts :)

Julien.P

On 29.02.2012 10:43, jpauli wrote:
> On Wed, Feb 29, 2012 at 9:18 AM, Pierre Joye<[email protected]> wrote:
>
>> hi Bill,
>>
>> On Tue, Feb 28, 2012 at 11:29 PM, William A. Rowe Jr.
>> <[email protected]> wrote:
>>> On 2/28/2012 3:41 PM, Sebastian Bergmann wrote:
>>>> On 02/28/2012 02:44 PM, Christopher Jones wrote:
>>>>> Build PHP with ZTS enabled by default. Allow it to be explicitly
>>>>> disabled during 'configure'
>>>>
>>>> Why punish everyone by default because of Apache? Does not make sense
>> to
>>>> me.
>>>
>>> What is so difficult to grok about
>>
>> Nothing, but it is easier to get a point when the rhetorical comments
>> are removed :)
>>
>>> 1. setting up php-cgi to use fastcgi as the httpd default.
>>>
>>> 2. having parallel non-zts and zts installs of php (notably with only
>>> non-zts cli and cgi sapi's) with two different lib paths. Multiply
>>> by two again if you have parallel i686 and x86_64 installs.
>>>
>>> All of these are packager's questions anyways, as so few users do this
>>> for themself, most hosters aren't rebuilding php either.
>>
>> Right, and that's a rather big change, package wised. While the
>> lbraries (systems) are the same, at lest for 99.99% of them. There are
>> a few which can be built in TS or not TS mode but I don't think it is
>> worth it.
>>
>>> PHP would be a much nicer, friendly and more civilized development list
>>> if it borrowed only one phrase from the Perl community; TMTOWTDI.
>>
>> Civilized sounds very wrong in this context, or in general these days.
>>
>> 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
>>
>>
> Right, I suggest we leave #61172 as is, as it solves the problem.
> PHP should be built with whatever MPM has been detected at configure time
> (httpd -V) , and that's all.
>
> The work of switching MPM later should be left to package maintainers, and
> scripts like Debian's "a2enmod" which can handle that themselves.

You could in fact add a safety net by querying the threadedness of the
MPM during mod_php startup. There's a standard MPM query API in Apache,
which tells you whether a threaded MPM is in use. If the mod_php build
would be without thread support and the module detects a threaded MPM
during startup, it could prevent startup of Apache and output an error
message.

Regards,

Rainer


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php