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."
Anybody still running Apache1 on Windows is nuts.
Apache2 works way better on Windows.
The problem that PHP can be linked against non-threadsafe libraries, and this causes issues with Apache 2 when it's using the Worker MPM. However, if PHP died and takes the thread with it Apache simple restarts it. I had Apache2 and PHP in this configuration for almost a year, and expect for threads randomly restarting because of PHP, I had no issues. If you want to solve the thread problem, change the MPM to prefork (which is the default last I looked), which emulates the Apache1 behavior, and stops that problem.
This signature was left intentionally blank.
Slashdot Mirror of Text: --- PHP's anti-Apache2 FUD My biggest objection to PHP is the anti-Apache2 FUD that they spread. Indeed, they seem to be the ones primarily responsible for the anti-Apache2 FUD. This is unfortunate, since there are few remaining legitimate reasons for avoiding Apache2, and it's a shame that they feel the need to manufacture one. So, to quote the PHP docs: Do not use Apache 2.0.x and PHP in a production environment neither on Unix nor on Windows. This is further clarified in the FAQ with a long description which starts, unfortunately, with a misconception, namely: The major feature that draws people to Apache 2 is threading. It then goes on to explain why threading is, potentially, a problem with PHP, why this is not, technically, PHP's fault, and so PHP cant fix it. All very correct, really. And, so, very logically, it concludes that there's no reason to move to Apache 2, and that everyone should stick with Apache 1.3. This argument suffers from one main flaw. That is, that the initial assumption, from which everything flows, is just plain wrong. Yes, threading is cool, and is a major shinyness with Apache 2. However, it is not, by any stretch of the imagination, the only, or even the main, reason for moving to Apache 2.0. There are a *lot* of other much better reasons for moving to Apache 2.0, none of which pose any threat to PHP. I've covered those in my OnLamp article, and so won't repeat them here. Apache 2.0, running with a prefork MPM, works great with PHP, and gives you all those other benefits. The additional benefit is a little more subtle. Apache 1.3 is becoming "legacy". Meaning that the real developers are focusing more on 2.0. The 2.0 docs are better. 2.0 (and 2.1) gets the new features, the documentation improvements, and the newly clarified directives and error messages. Thus, 1.3 becomes harder and harder to support. So, increasingly, the PHP questions are coming from folks that are running 1.3, and the solutions offered just don't work, because they are things added in 2.0 to solve exactly the irritations that these folks are having. So, I entreat the PHP folks to remove this incorrect anti-Apache 2.0 tirade from their documentation, and replace it with a more balanced and correct explanation of the issues involved, and the recommended solution. Namely, that people go ahead and move to Apache 2.0, but stick with a Prefork MPM. This gives them most of the benefits of Apache 2.0, but removes the irritating threading issues. Nobody blames PHP for those threading issues (at least, people who have taken the trouble to actually understand the issue don't), so there's no slight on the PHP developers implied here. I'd be glad to participate in this to any degree that you like. I actually enjoy writing documentation, and I'm increasingly using PHP for my own work. Please?
This signature was left intentionally blank.
I guess the only reason i can think of not to use PHP on Apache-2 ... is if you absolutely HAVE to use a threaded version of Apache-2.
... is the fact that PHP keeps continuously crashing your httpd-processes.
... but looses the benefits the threaded-MPMs offer.
... i would jump right on it :)
.. i never experimented with a threaded apache-1.3 (not even sure if that's possible) ... but for Apache-2 with the current state of PHP .. it's not recommended ...
THe apache-2 (Worker MPM) itself is rock solid and definately seems to boost performance of ones http-server compared to traditional apache-1.3.
I am not exactly sure about a prefork-MPM vs apache-1.3 comparison.
The biggest problem with PHP on any threaded Apache-2 (i am not sure if this holds true for the 1.3 series as well)
Switching to the prefork MPM makes everything rock-solid again
If PHP could actually solve their problems with running in a threaded Apache-2
Again
Apache 2.0 has proven to have so many new features that it was well worth the upgrade. Early on we encountered some minor issues with the threads, so we switched to pre-fork and have had no issues. We have been running PHP and mod_perl in pre-fork mode without a single issue for the last year. Unless you cannot switch because you use a module with no 2.0 support, I would make the switch immediately. And don't forget, you can always install both apache 1.x and 2.0 to give it a test run.
Read the thread, here
S
From what I've gathered, Apache2 is a reimplementation and 1.x is just in maintenence mode (security fixes etc)
All due repect (and I have a lot of it), but:
Either PHP itself, or many PHP applications, are not written to deal with the multi-threading offered by Apache 2.0.
That's just plain not true. 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).
S
This isn't to say that Apache is worthless. On the contrary, it is an exceptionally good server. It just doesn't scale as well as some others for static content.
-----
Free P2P Backup, Windows & Linux
I amde the switch over to Apache 2.0 and PHP 5 about 3 weeks ago at this point and have found it to be rock solid so far. My impression was that the PHP guys are recommending PHP4 for Apache 1.3.x and PHP5 for Apache 2.0.x. So in translation what they are not recommending is PHP4 on Apache 2.0.x. Perhaps I have gotten the wrong impression but that's what I got...
Power Corrupts,Absolute Power Corrupts Absolutely, leaving one person(group)in charge is absolutely corrupt.
The CGI may be a little slow to start up a PHP interpreter, etc etc, but it is rock solid. That said, using a real multithreaded application server (like, oh, any of your Java app servers) with Apache 2.0 is the best solution.
It's on the download page:
"Apache 2.0.52 is the best available version"
"Apache 1.3.33 is also available"
The message would appear to be '2.0.52 is the best, but if you insist you can get a lesser version'.
The memory pools in Apache 2.x (apr_pool_t) are quite inefficient. They have per-thread pools of memory that are only released when a thread finishes processing an HTTP connection. Apache 2.x uses more memory than Apache 1.3.x as result. I see no reason to switch from the very efficient Apache 1.3.x line.
It's very simple. We want people to move to 2.0, but since people have not done so, we're not going to leave them high and dry.
Apache guy, Open Source enthusiast, runner
I sustain 5 million hits per day on an Apache2+PHP server that (for me) indicates it's a "do-able" platform to run with.
Slashdot? Oh, I just read it for the articles.
Bruce
Bruce Perens.
Allow me to clarify something if I may. I'm not suggesting that everyone needs to migrate to Apache 2.0 today. I'm suggesting that PHP not strenuously discourage people from doing so. Those are two rather different things.
I hardly think that my posting (which, of course, nobody can read now because my server in my bedroom is melting. *sigh*) qualifies as unimitigated flames.
And I *certainly* don't presume to speak for the whole Apache community. It was just some (I thought0 harmless observations.
Apache guy, Open Source enthusiast, runner
Most of the benchmarks I've seen for Apache 2.0 on linux have been pretty ambivalent; the prefork MPM is generally better at ramping up to handle large numbers of connections, and serves more reqs/sec under high load, while the worker MPM serves large numbers of requests to small numbers of connections more efficiently. But those numbers seem to fluctuate based on the application and the number of processors used, and I've seen some applications where one model was nearly twice as efficient as the other--and I've seen that big a difference work in favor of both models, for different apps (which probably points to some MPM-specific design decisions in that particular application).
As always, the decision over whether to use threads or processes should be based primarily over whether you want to give up protected memory within your application or not (unless you're dealing with a platform like Windows where the process model simply isn't flexible enough to avoid throwing memory protection out the window).
rage, rage against the dying of the light
To their defense, the PHP folks say the problem is with libraries they don't control. But there could be a thread-safe PHP interface to them.
And I guess the bottom line is that they don't want to keep answering questions about this, so they just say don't upgrade to Apache 2.
Me, I use Zope. I think it's always been multithreaded.
Bruce
Bruce Perens.
PHP depends on a large number of external libraries that may or may not be thread-safe, and in many cases they are claimed to be thread-safe but aren't. Throw in the fact that some of these libraries are system libraries and the problems may not be reproducible on other systems, and you realise that making "PHP" thread-safe (in reality, making all the libraries it depends upon thread-safe), or even just tracking down where the problem lies, is a massive problem. The PHP devs have essentially said "not our problem, and we can't fix it".
None of this, of course, is a reason to avoid Apache 2. Apache 2 can run in prefork mode, just the same as Apache 1. That's why the PHP documentation telling everyone to avoid Apache 2 is FUD.
Unfortunately, the threaded models Apache 2 could otherwise use are one of the major attractions of upgrading. In particular, running different websites under different uids is only possible with the threaded MPMs, which is a *huge* deal for hosting providers, PHP's main installed base. Well, it's possible by running multiple copies of Apache and a proxy on port 80, but nobody wants to do that.
Bruce
Bruce Perens.
In my experience, FrontPage actually works quite a bit better with Apache 2.0. FrontPage for Apache 1.x requires patching your Apache or downloading pre-patched binaries from rtr.com or Microsoft. FrontPage for Apache 2 can load cleanly as a module, no server modifications needed.
If you want the offical notice of Apache 2 support, see here.
lighttpd is a pretty good up-and-coming alternative I've been testing lately. It's faster than apache for both static and dynamic (php, python, ruby) content.
You can run both Subversion and PHP 4 concurrently in Apache 2.0. We've been doing it sucessfully for several months now with no problems in prefork mode. No need for two versions of Apache when one will do.
IIRC, it was a license issue. The AFS wanted the PHP project to switch to using one of the ASF licenses while the PHP folks did not. PHP is still listed as a sister project. It's just not under the official ASF umbrella.
Slashdot: Failed Car Analogies. Amateur Lawyering. Anecdote Battles.
Well perchild was supposed to provide this functionality, but it's unmaintained and nonfunctional from what I understand. Even if it does work it has security problems. On top of that it's a threaded MPM, so it carries the same thread-safety issues that worker does for PHP.
There are some of us who are attempting to provide a working alternative. The MetuxMPM project can be considered a working implimentation of perchild, although still in development. It still uses the threaded model but doesn't suffer the same security issue.
I required a non-threaded solution, so I started my own MPM project, using prefork as a base but copying in a lot of code from metuxmpm. I call it "peruser". Right now it's a lot more clunky than metuxmpm. I'm also not a professional C or apache programmer, so if anyone out there wants to help I'd really appreciate it.
Neither of these projects is really well-suited for a small number of websites that do a lot of traffic. They're more aimed at shared hosting providers who want to provide better security than php's safe_mode.
Here's the links:
MetuxMPM
Peruser (nonthreaded version of metuxmpm)
As much as I respect you after meeting you at the NC Biotech center in May of 97(?), I think you need to think that through completely. I've tried this with a site so I could use an old version of pdflib. Performance was a major problem. If you have only a single Apache thread that can access an often used library function at a time, you have a bottleneck. With multiprocess servers, that isn't a problem. The original UNIX process model works well and is simply safer.
No, the PHP folks specifically tell you not to run PHP with Apache 2.0. It is in their FAQ on their website.
What seems to be lost in the noise is that PHP guys are not saying there is anything wrong with apache2. They are acknowledging that not all the extentions in PHP are thread safe.
In other words it's PHP at fault and not apache2 and they are admitting it.
evil is as evil does
You raise an excellent point. If the data you are serving up is highly sensitive then you are better served by the forking model which has a process wall between the data in your HTTP connections. You never know what kind of bugs a module will exhibit in a multithreaded scenario.
Absolutely. But it's not merely protecting sensitive data--OS architects worked hard for years to implement protected memory, and threads circumvent a lot of those gains (a bug in one thread can affect them all, all memory access needs to be synchronized, etc).
There are good times to use them, but the choice should be based on whether you need to share all (or most) of the memory as opposed to sharing little or none (when processes, possibly with shared memory segments, are the correct choice).
Too many people think that somehow "threads are faster" when (excepting egregious disparities a la Windows) that isn't necessarily true--and even when it is, the performance benefits are often tiny compared to the costs you pay.
rage, rage against the dying of the light
It still seems to me to be an architecture issue.
Bruce
Bruce Perens.
Yes it does. The only exceptions are SYSV IPC objects which don't get automatically reaped, and temporarily created filesystem objects that still have links.
Assuming your kernel isn't buggy, anyway.
DNA just wants to be free...
from the docs:
Do not use Apache 2.0.x and PHP in a production environment neither on Unix nor on Windows.
If you know anything about webhosting you know that cPanel/WHM (and competitors, e.g. DirectAdmin, Fantastico, etc) still support the stodgy old Apache 1.3/mod_php model. The vast majority of sites out there run on cPanel or some other type of shared/reseller type of control panel/managed hosting software. Until this changes, don't expect Apache 2.0 to make any inroads.
That said, everyone should hope 1.x to die ASAP. Basically the Apache developers have to do double duty maintaining two completely seperate branches. If everyone could let 1.3 die then there would be a LOT more manpower available to concentrate on 2.0. For many many years they have said that no new features are going into 1.3 -- everything is happening on 2.x. Yet they still have to maintain security fixes and chase down bugs on the 1.3 branch which is very creaky. There is a reason, after all, that they decided to rewrite everything for 2.x.