Slashdot Mirror
Is Apache 2.0 Worth the Switch for PHP?
An anonymous reader writes "It seems like some of the members of the Apache Software Foundation are a little angry with the PHP Community because they don't recommend using Apache 2.0 with PHP. Since PHP is installed on half of all Apache servers this is a major issue for them. A number of high-profile PHP community members such as John Coggeshall and Chris Shiflett have blogged about this decision in light of a recent posting by Apache Software Foundation Member Rich Bowen which called PHP's anti-Apache2 stance FUD. Is there any real reason for the PHP community to start recommending Apache 2.0, especially when the 1.3.x series of Apache is rock solid and proven? Note Rich did later commend PHP for being a great product, so it's not all flames."
Well, as the article probably says.. Many of PHP's modules aren't thread-safe. So there'll be little errors that might not show up until you have thousands of concurrent accesses. This of course can be solved by using the pre-fork config for Apache2..
Can anyone point me to a succint explanation of why there have been an Apache 1.x line and an Apache 2.0 line for years? This to me has always seemed like an implicit statement from the Apache people that I should not yet move to 2.0.
I checked the front page of Apache and there were release announcements for the latest version of both lines. Neither announcement carried a statement indicating when you should use it over the other. The front page does not appear to link to anything addressing the issue, and the FAQ does not appear to handle it, either.
Secession is the right of all sentient beings.
I beg to differ. Apache 1 or 2 for that matter is no where near the maximum performance level when it come sto serving static content.
As projects such as thttpd, tux, boa, lighttpd and many others clearly demonstrate. In fact the performance of Apache 1/2 is no where near what the solutions I've mentioned offer.
As mentioned (probably more than once by now), the only issue is some non-thread-safe libraries that PHP can link to. Configuring Apache to run with the "Prefork" MPM solves this problem (by running with the same model as Apache 1.x did).
I see no reason so far to discourage use of Apache 2.0 with PHP other than vague "well, I heard from some guy that he tried it and it had some kind of problem" sort of complaints. Personally, I like the fact that Apache 2.0x has mod_ssl and mod_deflate (/mod_gzip) as part of the codebase, so I no longer have to compile and install them separately...
Hacker Public Radio is our Friend
it must be useless for anyone who wants php. That seems to be the main theme of these posts. Just because a feature doesn't provide much to a pure php setup doesn't mean that there aren't people who want to run php as part of their site but still need some of what apache 2 offers. Seems pretty short-sited.
The /. moderators really don't have any control over what appears on /. or not...you should be ticked off at the Editors!
Doh!
Apache 1.3 has been working flawlessly for me. Until I have a compelling need to switch to Apache 2.0, I'm not going to. I understand that there are some nifty new features in Apache 2.0, but not a single one of them is something that I want/need.
Exactly. This is happening with a lot of free software lately, namely the Linux kernel... I used to keep up-to-date on the kernel just because it was always getting better.
2.4.x has been rock solid for me and 2.6.x just doesn't offer anything to me that makes me compelled to move to it (in fact I had issues w/my ethernet cards working under it).
Apache 1.3.x has been absolutely fine and continues to update via apt-get/aptitude. Why should I bother with 2.0.x? Give me one reason why this needs to be an issue? PHP people think that PHP runs better under 1.3.x and Apache continues to develop that version. I don't see the problem.
Apache, if you don't want people to use 1.3.x stop development and give people a good reason to switch.
The underlying threading problem has little to do with PHP, and absolutely nothing to do with PHP applications, but libraries to which PHP links (libmysqlclient, libpdf, libmcrypt, etc etc etc). It's these third-party libraries (over which the PHP developers have no control) that cause Apache2 to be unstable in the various threading modes (prefork works fine, but is just not officially supported).
:-)
Sounds exactly like the wonderful world of Windows programming
Yeah, be very affraid of new technology, it could be better and force you to upgrade.
Anybody still running Apache1 on Windows is nuts. I think a better way to phrase it is: Anybody running Apache on Windows is nuts
I spoke to the Zend guys about this at OSCON six months ago. They said they had a suexec version of PHP in "private Beta". I sent them several emails afterwards asking whether we could test it / help out etc, and haven't received a single reply, so I have no idea whether that's still coming.
Anyone have any more info on this?
cLive ;-)
-- Trinity in high heels carrying a whip: The donimatrix - there is no spoonerism
PHP spread FUD about Apache2 because that's what they *THINK* of it.
[F]ear - what if my PHP processes crash?
[U]ncertainty - has this thing been tested yet?
[D]oubt - Hmmm I'm not sure...
And as far as I know, no one has dared to make a COMPLETE TEST of PHP running with Apache2, explaining which PHP modules fail and why.
In other words, it's simply FEAR OF THE UNKNOWN what the php community has about Apache2.
You have raised some crucial points. I have been running PHP on my production servers for several years now, but I have always wanted answers to these questions. As time goes on I am amazed at the total silence, and actually the fact that more people are not asking the same questions. Or else, maybe I am an idiot and I am not understanding some fundamentals.
1. why is magic_quotes_gpc on by default? Every time I install PHP somewhere I need to go into the global php.ini and turn this off. Even worse, when I am deploying code on someone else's machine where php_admin_flag is ignored in htaccess, I have to do a bunch of nested stripslashes crap to undo this. It is a fucking nuisance to have my form input contaminated in a way that PHP decides I might like. Can't we put the onus on developers to actually write secure database code, and stop creating headaches for those of us who can?
2. why oh why can we not invoke PHP via mod_php as specific users? This is a no-brainer for a shared (read: any) system. Otherwise we are forced to use the CGI version in order to have any semblance of security, which completely negates the wholesome goodness of mod_php. Admittedly, my system is small enough that so far I have still been running mod_php with the kind of "weird things to ensure security" that you note. It is half-assed though!
(Bonus question not related to PHP: why can we use server-wide CustomLogs which pipe to a command in order to split up logs by host, but not do the same for ErrorLogs? I am wasting a file descriptor for every virtual host just for its own ErrorLog, while I am absolved of this for the access logs. What am I missing here?)
-ben
myselfmusic
Stop being so mean! It's not PHP's fault they can't run in a thread model. Threads have only been commonplace for 25 years, and the standard way you do things for 15.
They just need some time to catch up. Apache 2.x is light years faster/leaner/meaner then 1.x was. Oh, and PHP runs perfectly fine under 2.x, as others have pointed out.
OK, so yea, it's actually kinda sad (read: pathetic)
- Adam L. Beberg - The Cosm Project - http://www.mithral.com/
From the blogs, it sounds to me like the php guys haven't recommended not using Apache 2, but rather have not recommended it. Although they haven't stated any harms aside from it's an unproven platform, they haven't found any benefits, either. So they said why bother.
Although on the surface that sounds pretty neutral, I can certainly understand Apache being concerned about this, considering how closely affiliated the two are (as the grandparent noted). I like analogies so imagine bringing home a couple of girlfriends over the years for Mom and Dad to meet. Then you meet an even better girl whom you invest a lot of effort into impressing and you're sure they'll love her, but instead they say, "what was wrong with your last girlfriend?" While your parents haven't said anything against your new lady friend, they've implied they're not impressed. I admit, dating is a poor analogy for some of the regulars here, but at least it was fun while lasted, right?
I agree that it sounds somewhat petty. Why not say something a little more friendly like, "We've seen great things from the Apache Foundation, and while we're not prepared to fully endorse version 2, we're anxious to see how it performs?" It's simple, generic, non-committal, open-ended, political-style BS, but it keeps people happy.
The horror of actually making solid software; nobody's upgrading.
Maybe Windows knows what it's doing after all.
PHP to rewrite bzlib? zlib? OpenSSL? MySQL? MSSQL? Oracle?
:p
I don't understand what you're getting at here. There are a TON of libs that PHP can be compiled to use/support that are completely 3rd party, and if the 3rd party lib isn't thread safe, it doesn't matter HOW locked down PHP is there are still going to be issues. If the thread gets destroyed or exploited outside of PHP in one of these other libs, HOW is that PHP's fault?
They made the statement that PHP on Apache2 was 'bad' because it would all roll back on them. This is mostly a CYA move on their part and one I don't blame them for taking. What I've read indicates that it works, but "Use At Your Own Risk" because they can't give a 100% guarantee that EVERYTHING is going to be safe. Look at it from the other end... different references for securing Apache2 have commented that if everything in your environment isn't thread-safe that there will be possible security and stability issues. The recommended approach is to ONLY use extension/modules/addons that are thread-safe. If we're saying that PHP is FUD'ing on Apache2 then almost all the securing Apache guides are FUD'ing all over ANYTHING that might not be 100% thread-safe that interfaces with Apache2.
> As I recall, an old benchmark showed that a 486 running Linux and Apache could saturate a T1 serving static content.
Static content is trivial for any webserver, and T1's are a piddly 1.544 megabits. I could probably write a webserver in shell script reading a line at a time and redirecting the output to netcat and still saturate a DS-1 (T1).
Apache 2 changes CORE functionality- great! But that doesn't really affect what it does, but rather how it does it. Maybe if it implemented some new HTTP 1.2 I would get it in there... but who'd notice?
Apache1 has been tried, tested, and true and has reached a lovely 1.3.33 version, of which security patches are rare and bugfixes are also rare. Similar situation with mod_ssl. So why leave your nice warm, structurally stable house in favour of the blistering cold to try something new that has a new version for bugs and security on a much more common basis? Personally, until Apache 2 gains some serious market share, I see no reason to leave. We provide hosting- and need reliability, and can't be wasting time with constant updates (though updates are better than not fixing of course) when we could otherwise stick with Apache 1.
Apache1 does one thing, and does it well. Period. Sure there are crazy new features of Apache2, and I've tried them else. Personally, I see nothing compelling to move at this point. There are a few small 'that would be nice' features, but really nothing exciting in the way of Linux2.6, WindowsXP, etc. Even 2.6 is having slow adoption. You can only find it on workstations, because no supportive provider is about to live on the bleeding edge and leave their customers bleeding. Apache on the other hand doesn't have a place on the workstation (unless it doubles as a causal server), so in the same way, you're trying to get those folks who prefer stable releases (like Debian stable) over bleeding edge.
So why switch?
"Bad press leads to lots of misinformed morons saying stupid things about how Apache 2 is not ready for prime time." -- I guess I'm one of those morons. Personally I'm not about to replace one of the core pieces of software between us and our customers with something that hasn't proven itself to me. We've set it up in testing environments, and found that it performed similarly and didn't offer anything new we need.
when you see the word 'Linux', drink!
ASF made a couple of mistakes in marketing:
o Apache2's biggest competitor is Apache1
o Making it run better on Windows does not win any market share for Apache2, since the installed base is Apache1
o Apache1 is being used on production servers, where people's jobs are on the line. No one really wants to be first unless there is a issue to be solved.
o MPM was mistakenly focussed upon as the selling feature. Just because MPM took the most effort doesn't mean it is the most compelling feature!
o Apache2 made the golden mistake of breaking the platform. Apache is a platform, because a lot of other software is built on top of it. The inability of Apache2 in its early development stages to be backwardly compatible with the Apache1 modules mean there wasn't much chance for people to test how Apache2 would behave in their original configuration. Currently, in many people's mind, Apache2 is being 'beta-tested' with PHP in the sense there are no real world data of PHP performance against Apache2.
o Apache2 may have broken compatibility with management tools that ISP uses as well. This again lowers the value of a platform.
Steps to take:
o PHP's biggest customers are ISPs. If Apache2 were adopted by ISPs then, all problems are solved. Partner with a large ISP, so that there are some sites running on Apache2 + PHP + other modules in their system. Offer to run profile information and offer round the clock support if the system goes down (see the problem with free software?) and publish good documentation + case studies based on this, so that other ISP's could migrate their systems over.
o Let's face it. Any code rewrite is going to break something - wrt to third party software. Somewhere. Apache2 being totally silent on this is being not credible. It simply points to the lack of adoption, and hence no one knows what is broken.
o I can't believe a ground up rewrite is not capable of offering any improvement. Apache2 has to study the key weaknesses in Apache1 either in resource consumption, scalability or performance to demonstrate what benefits can be achieved. Some real world benchmarks would be useful here.
o Failing all the technical marketing, Apache2 could focus on some hype. Get ISPs to differentiate themselves with "Runs on Apache 2" campaign, pointing out other ISPs are still running on "Apache 1".
Hint: Don't wait until the media says linux is desktop-ready.
If at first you don't succeed, skydiving is not for you