Apache 2 and PHP stable yet?

Folks,

This must get asked reasonably often however I've had tried viewing
groups.google.com and the apache/php web pages and not found a specific
answer.

Basically, is Apache 2 officially supported with PHP, and if so, which
version of PHP?

The last I heard the PHP website had Apache 2 with PHP4 running for
something like two years, but the support was still not official for a
production environment.

Thus - Is PHP still officially only supported on Apache 1.3? Or, which
version of PHP is considered stable for Apache2.

Thanks - replies via newsgroup please, so all can learn,

Randell D.

I'm responsible for a number of servers running Apache 2.0 and both PHP 4
and 5. These machines serve well over a millinon hits per day each. I have
not had any problems with either combination to date.

The Apache 2.0, PHP 4+, MySQL 4+ setup seems very solid to me. I'm not sure
if it's officially supported though. But than again, what does official
support mean in the open source world anyway?

However, be sure to run it on hardware supported by your OS vendor. The only
tough problems I've ever encountered were always due to unsupported
hardware/driver issues.

Balazs

"Randell D." <reply.via.newsgroup.thanks@fiprojects.moc> wrote in message
news:faptf.25897$OU5.11188@clgrps13...
>
> Folks,
>
> This must get asked reasonably often however I've had tried viewing
> groups.google.com and the apache/php web pages and not found a specific
> answer.
>
> Basically, is Apache 2 officially supported with PHP, and if so, which
> version of PHP?
>
> The last I heard the PHP website had Apache 2 with PHP4 running for
> something like two years, but the support was still not official for a
> production environment.
>
> Thus - Is PHP still officially only supported on Apache 1.3? Or, which
> version of PHP is considered stable for Apache2.
>
> Thanks - replies via newsgroup please, so all can learn,
>
> Randell D.

PHP may not work with the multithreaded worker MPM in Apache 2.0, but
it will work with the prefork module.

Randell D. wrote:
> Basically, is Apache 2 officially supported with PHP, and if so, which
> version of PHP?

As far as I know no versions of PHP officially supports Apache 2. The
SAPI modules are still marked "experimental" in the most current source
code.

> The last I heard the PHP website had Apache 2 with PHP4 running for
> something like two years, but the support was still not official for a
> production environment.

Well, that's PHP development for you. Apparently there are issues of
higher priority than actually getting the stuff to work in a production
environment.

> Thus - Is PHP still officially only supported on Apache 1.3? Or, which
> version of PHP is considered stable for Apache2.

The Apache 2 SAPI module has an ugly memory leak in versions prior to
4.3.9. One byte is lost for every byte sent to the web server. During
typical operation this doesn't have a large effect, as Apache restarts
each child process after it has handled a certain number of requests.
If a script outputs large amount of data (i.e. multi-megabyte file
downloads), then you have a problem.

Chung Leong wrote:

> Randell D. wrote:
>
>> Basically, is Apache 2 officially supported with PHP, and if so,
>> which version of PHP?
>
> As far as I know no versions of PHP officially supports Apache 2.

Define "support" in the context of Open Source.

> The SAPI modules are still marked "experimental" in the most current
> source code.

Regardless, as has been posted already, many people do use Apache 2 and
PHP in production environments.

>> The last I heard the PHP website had Apache 2 with PHP4 running for
>> something like two years, but the support was still not official for
>> a production environment.
>
> Well, that's PHP development for you. Apparently there are issues of
> higher priority than actually getting the stuff to work in a
> production environment.

But it already works in a production environment! Have you tried it?

>> Thus - Is PHP still officially only supported on Apache 1.3? Or,
>> which version of PHP is considered stable for Apache2.
>
> The Apache 2 SAPI module has an ugly memory leak in versions prior to
> 4.3.9. One byte is lost for every byte sent to the web server. During
> typical operation this doesn't have a large effect, as Apache restarts
> each child process after it has handled a certain number of requests.
> If a script outputs large amount of data (i.e. multi-megabyte file
> downloads), then you have a problem.

I've been using Apache 2 with PHP outputting megabytes of files with no
problems.
--
He's not dead, he's electroencephalographically challenged.

Andrew DeFaria wrote:
> Define "support" in the context of Open Source.

Software that isn't a joke? The following sounds like a joke to me:

"this module is experimental,
its functions may change their names
or move to extension all together
so do not rely to much on them
you have been warned!"

> Regardless, as has been posted already, many people do use Apache 2 and
> PHP in production environments.

Okay, so people are supposed to make a important business decision
based on some messages they read on a newsgroup? Jesus. The big issue
is not whether it actually works but who's responsible when it doesn't.
If I'm pushing a setup that's described as experimental and something
goes wrong, who's responsible? Me.

Seriously, how long does this "experiment" have to last? Is it that
hard for them to run some tests to see if the thing works or not?

> But it already works in a production environment! Have you tried it?

Of course. And I have egg on my face to show for. I have to say, I
rather dislike having to apologize to an important client for someone
else's bugs.

> I've been using Apache 2 with PHP outputting megabytes of files with no
> problems.

If you don't believe me, take a look at the CVS:

http://cvs.php.net/viewcvs.cgi/php-s...og#rev1.1.2.32

Yes, I actually had to rummage through the source to see when the leak
was plugged because the fix wasn't mentioned in the changelog. I had
been warned I suppose.

> Okay, so people are supposed to make a important business decision
> based on some messages they read on a newsgroup? Jesus. The big issue
> is not whether it actually works but who's responsible when it doesn't.

You are! That's the beauty of open source. If you don't like the way it
works, fix it! On the downside there's really no one single entity to blame
if it doesn't work.

> If I'm pushing a setup that's described as experimental and something
> goes wrong, who's responsible? Me.
>

It sounds to me like you have a decision to make. Go with open source or
proprietary software. If you want someone else to blame in case something
goes wrong you can pay the license fees for a product that has commercial
support behind it like Microsoft or Sun. Although in my opinion the open
source community is often more responsive and more helpful than having to
wait for some software giant put your trouble ticket through its hoops while
it is being escalated through the various support levels.

> Seriously, how long does this "experiment" have to last? Is it that
> hard for them to run some tests to see if the thing works or not?
>

The life cycle of open source products are typically longer than that of
proprietary software. Open source products are usually released when they
are ready not when marketing says so. I think this is a good thing. It keeps
the quality of software higher while maintaining more realistic user
expectations. If it's in beta you should understand what you're getting
yourself into.

>> But it already works in a production environment! Have you tried it?
>
> Of course. And I have egg on my face to show for. I have to say, I
> rather dislike having to apologize to an important client for someone
> else's bugs.
>

Sorry, but I don't think that's fair. If you had done your job you would've
discovered any flaws or problems before a production deployment. It's up to
you test your own setup. Of course, I'm not aware of the details of your
situation, I could be wrong.

Remember, you're getting an incredible product in PHP for free! If you want
commercial support for it you might want to look at a third party company
like Zend. www.zend.com

My 2 cents,
Balazs

Chung Leong wrote:

> Andrew DeFaria wrote:
>
>> Define "support" in the context of Open Source.
>
> Software that isn't a joke? The following sounds like a joke to me:
>
> "this module is experimental, its functions may change their names or
> move to extension all together
> so do not rely to much on them you have been warned!"

You failed to define the term support in the context of Open Source. Try
harder next time.

While the above may sound like a joke to you it doesn't to me. Indeed
the above statement doesn't even name the module. For all I know it
could be a portion of something bigger.

>> Regardless, as has been posted already, many people do use Apache 2
>> and PHP in production environments.
>
> Okay, so people are supposed to make a important business decision
> based on some messages they read on a newsgroup?

Yes! It's done all the time. In fact I do it all the time!

Some businesses in the orient use Feng Shui for their business
decisions. Is that really any better?

> Jesus. The big issue is not whether it actually works but who's
> responsible when it doesn't.

Ah no, not at all. If the software works then nobody needs to worry
about being responsible when it doesn't because it does. This is simple
logic. Are you sure you're a real programmer?

> If I'm pushing a setup that's described as experimental and something
> goes wrong, who's responsible? Me.

Then test it. Or spending thousands or millions of dollars on inferior
off the shelf software that - guess what? - has bugs too. Some of this
off the shelf software with their support contracts and all are based
off of Open Source stuff anyway (e.g. IBM/Rational's web server
software, called RWP, is basically Apache).

I find that some people focus on and worry about your statement so much
that it essentially stifles them totally into no action at all. I used
to be like that. Then I saw the light - the real issue is whether or not
it works not whether or not you can blame.. ahem... call somebody else
for support. Ever call somebody else for support and you end up
informing them about how their software works?!? You may not have but I
sure have! So again, what is support mean in the context of Open Source?
And what does support really mean in the context of non Open Source?
After years of experience I've learned that the later is not really
significantly better than the former. YMMV.

> Seriously, how long does this "experiment" have to last?

Maybe it's no longer an experiment rather they just haven't changed the
tag. How long will this American experiment last? Been going for over
200 years. Been going long enough for most people in the world to invest
it in...

> Is it that hard for them to run some tests to see if the thing works
> or not?

Have you actually used Open Source at all? Have you actually tried to
build it yourself? Often (i.e. every time I've done it) it has tests
built in. For example, CPAN modules will configure their Makefiles,
compile and run tests before installing. Question: How many tests do you
need and how many of them need to pass? One person may have 100 tests
and 80 of them pass and he labels this as experimental just because 20
of them fail. But if you do not use any of the functionality in those 20
tests do you really care?

>> But it already works in a production environment! Have you tried it?
>
> Of course. And I have egg on my face to show for. I have to say, I
> rather dislike having to apologize to an important client for someone
> else's bugs.

Get used to it! No software is bug free! The trick is to get the
software with bugs in functionality that you don't care about.

(BTW if software were bug free then getting support would be irrelevant!)

>> I've been using Apache 2 with PHP outputting megabytes of files with
>> no problems.
>
> If you don't believe me, take a look at the CVS:
>
> http://cvs.php.net/viewcvs.cgi/php-s...og#rev1.1.2.32
>
> Yes, I actually had to rummage through the source to see when the leak
> was plugged because the fix wasn't mentioned in the changelog. I had
> been warned I suppose.

Hmmm... Funny:

Revision *1.1.2.32* - (view
<http://cvs.php.net/viewcvs.cgi/php-src/sapi/apache2handler/sapi_apache2.c?hideattic=0&view=markup&rev=1.1.2.3 2>)
(download
<http://cvs.php.net/viewcvs.cgi/*checkout*/php-src/sapi/apache2handler/sapi_apache2.c?rev=1.1.2.32>)
(as text
<http://cvs.php.net/viewcvs.cgi/*checkout*/php-src/sapi/apache2handler/sapi_apache2.c?content-type=text%2Fplain&rev=1.1.2.32&pathrev=1.1.2.32>)
(annotate
<http://cvs.php.net/viewcvs.cgi/php-src/sapi/apache2handler/sapi_apache2.c?annotate=1.1.2.32&hideattic=0>)
- [select for diffs]
<http://cvs.php.net/viewcvs.cgi/php-src/sapi/apache2handler/sapi_apache2.c?hideattic=0&r1=1.1.2.32&view=log>

/Fri Jun 25 12:51:38 2004 UTC/ (18 months, 1 week ago) by /edink/
Branch: *PHP_4_3*
<http://cvs.php.net/viewcvs.cgi/php-src/sapi/apache2handler/sapi_apache2.c?view=log&hideattic=0&pathrev=PHP_4_ 3>

Changes since *1.1.2.31: +3 -25 lines*
Diff to previous 1.1.2.31
<http://cvs.php.net/viewcvs.cgi/php-src/sapi/apache2handler/sapi_apache2.c?hideattic=0&r1=1.1.2.31&r2=1.1.2.32 >
, to branch point 1.1
<http://cvs.php.net/viewcvs.cgi/php-src/sapi/apache2handler/sapi_apache2.c?hideattic=0&r1=1.1&r2=1.1.2.32>


_Memory leak fix_ (patch by Joe Orton)


Seems pretty clear to me that it was fixed *18 month and 1 week ago!!!*
--
I(nternal) R(evenue) S(ervice): We've got what it takes to take what
you've got.

Balazs Wellisch wrote:
> You are! That's the beauty of open source. If you don't like the way it
> works, fix it! On the downside there's really no one single entity to blame
> if it doesn't work.

It is one thing to fix a software flaw. It is quite another when the
problem is in the development process. The only way to fix it is to
fork--another beauty of open source I suppose.

> The life cycle of open source products are typically longer than that of
> proprietary software. Open source products are usually released when they
> are ready not when marketing says so. I think this is a good thing. It keeps
> the quality of software higher while maintaining more realistic user
> expectations. If it's in beta you should understand what you're getting
> yourself into.

I think you're taking a particular case and fairly generalizing it over
all open source products. It's certainly not a common practice to
release software with critical components marked as experimental. We're
not talking beta versions here. This has been the case for the last
dozen production releases or so.

> Sorry, but I don't think that's fair. If you had done your job you would've
> discovered any flaws or problems before a production deployment. It's up to
> you test your own setup. Of course, I'm not aware of the details of your
> situation, I could be wrong.

I guess it was my fault to assume that the software would work
correctly at the most basic level. Why, even the developers themselves
don't know if it works or not. I'm clearly a fool in choosing the open
source route.

> It is one thing to fix a software flaw. It is quite another when the
> problem is in the development process. The only way to fix it is to
> fork--another beauty of open source I suppose.

I'm not sure I understand your point. What exactly do you see as a problem
in the development process?

Forking is typically not done to fix bugs. You can create a fork if you want
to take product development in a new direction that's more suitable for your
own needs. To fix a bug you can simply submit a patch for the current
release.

>
> I think you're taking a particular case and fairly generalizing it over
> all open source products. It's certainly not a common practice to
> release software with critical components marked as experimental. We're
> not talking beta versions here. This has been the case for the last
> dozen production releases or so.

Well, sure I am generalizing since we're having a discussion about the
merits of open source development. It is in fact a necessity for open source
to "release" software in an experimental state. Most projects have nightly
builds that can be downloaded, worked on and then released again. This is
how things get done. This is why open source is more powerful. Anyone can
download the software and contribute to its development. Potentially there
could be tens of thousands of programmers working on a project, fix bugs,
add features, etc. No software manufacturer can compete with that.

> I guess it was my fault to assume that the software would work
> correctly at the most basic level. Why, even the developers themselves
> don't know if it works or not. I'm clearly a fool in choosing the open
> source route.

It depends. If you're installing software on a production system than you're
playing the role of a system administrator. System administrators are
responsible for the operation of hardware and software. As such you should
have intimate knowledge of every component you install and you should be
able to fix any problem that occurs. Whether you do it yourself or through
support from a community or a company is up to you. But, you are responsible
for taking the necessary steps to ensure the operation of your server.

If you're a developer than you have every right to expect the server you're
working on to function as advertised. But if something goes wrong, guess
who's blamed? The sys admin! So, if you're playing both roles, ultimately it
is you who gets blamed!

It sounds to me like you're a little bitter about something that went wrong
and perhaps you lost some of your objectivity in the process. Why don't you
elaborate a little more on your problem? Perhaps we can help!

Balazs