httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe Jr." <wr...@rowe-clan.net>
Subject Re: PHP5.3.6
Date Fri, 18 Mar 2011 22:02:27 GMT
On 3/18/2011 9:24 AM, Rich Bowen wrote:
> I wanted to be sure that folks are aware of what's going on in the Windows/PHP world.
I know that, in one sense, it's not our problem, but it *feels* like our problem to me, and
to many of our users.

Quite honestly, this leaves me with a taste to simply drop Windows
builds altogether, and let the competing groups all prove up their
own solutions.  (including PHP, if they had the sense to ship an httpd
build of their choice).  This is little different than the competing
binary builds for linux.  There is an argument for, and available
packages to install an entire lamp stack at once.  They can do this
because licensing the AL+MIT+GPL bits together is no issue to them.

In reality, there's next to no reason to load PHP in process, I know
of several engineers who have profiled the system load of in process
mod_php vs. mod_fcgid with appropriately sized pools of php single
processes with no threading.  Very few deployments merit a 1:1 allocation
of php workers to httpd workers, and this will become more striking as
we move forward towards more asynch models.  Of course a smaller number
of single threaded php workers always wins, because PHP threading has
reasonably high mutex contention, although I'm aware that the BDfL of
php on win32 strongly disagrees with such results.

But keep in mind, mod_perl and mod_python also suffer these issues, and
they are interlocked into particular msvc runtimes that ActiveState,
strawberry perl and others had elected.  Even within their current
shipping products, at any given time ActiveState perl and python are
generally built with a different msvc flavor.  Interesting for PHP to
join the effort to further fragment the picture, today.  (Yes, strawberry
perl is an msys based build, but one that links in msvcr80).

As I noted, switching now to VC9 when VC10 has been out for some time
now is ass backwards.  Within months [some 1 to 3 of them] there will
be a finished 2.4.0 (which will be waiting for PHP binaries).  If I go
to the trouble of even offering some binaries, they certainly won't be
using an already stale toolchain.

The only sensible alternatives seem to be MSYS (and there too there is
a question of which msvcrt version) or Mladen's proposal to stay with
msvcrt, which I'm almost favoring right now.

Mime
View raw message