Is Apache 2.0 Worth the Switch for PHP? 465
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."
apache2 is essential for Windows (Score:3, Informative)
Apache2 works way better on Windows.
FUD in it's purest form ... (Score:5, Informative)
The site appears to be struggling (Score:1, Informative)
PHP and Threaded Apache (Score:3, Informative)
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
Well worth the upgrade (Score:3, Informative)
Re:PHP used to be an ASF project (Score:3, Informative)
S
Re:Why are there two?? (Score:2, Informative)
Re:apache2 is essential for Windows (Score:4, Informative)
Re:It's a threading issue (Score:5, Informative)
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
Slashdot uses Boa for images (Score:5, Informative)
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.
Making the sqitch (Score:3, Informative)
Re:It's a threading issue (Score:3, Informative)
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.
Re:Why are there two?? (Score:5, Informative)
It's on the download page [apache.org]:
"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'.
Apache 2.x memory model is bizarre (Score:1, Informative)
Re:Why are there two?? (Score:5, Informative)
How many hits? (Score:5, Informative)
Re:It's a threading issue (Score:5, Informative)
Bruce
Um ... that's not quite what I said (Score:2, Informative)
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.
Re:It's a threading issue (Score:5, Informative)
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).
Re:It's a threading issue (Score:5, Informative)
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
Re:Nobody told me! (Score:3, Informative)
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.
Efficiency is not entirely a web server function (Score:5, Informative)
Bruce
Re:Frontpage (Score:3, Informative)
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 [rtr.com].
Re:I think they're right (Score:3, Informative)
Re:Apache 2.x memory model is bizarre (Score:5, Informative)
Bruce
Re:PHP and Subversion (Score:4, Informative)
Re:PHP used to be an ASF project (Score:5, Informative)
Re:Using PHP on Apache 2.0 right now. (Score:2, Informative)
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 [metux.de]
Peruser (nonthreaded version of metuxmpm) [telana.com]
Re:It's a threading issue (Score:1, Informative)
Re:PHP used to be an ASF project (Score:5, Informative)
Re:PHP used to be an ASF project (Score:5, Informative)
In other words it's PHP at fault and not apache2 and they are admitting it.
Re:It's a threading issue (Score:5, Informative)
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.
Rewriting libraries (Score:3, Informative)
It still seems to me to be an architecture issue.
Bruce
er, no... (Score:4, Informative)
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.
this is untrue. (Score:5, Informative)
Do not use Apache 2.0.x and PHP in a production environment neither on Unix nor on Windows.
Re:apache2 is essential for Windows (Score:3, Informative)
On NT, instead of creating 64* threads [apache.org] (or whatever the maximum number of concurrent clients will be, possibly hundreds) where one thread waits on each connected client, it would be better to create about 1 thread per CPU and have them take work items off of a completion port [microsoft.com]. Instead of blocking on IO, always do it asynchronously and have the result posted as another work item.
Both files and sockets can be connected to completion ports. Always have a pending read on open sockets so when a packet is recieved, the OS posts a work item.
Client wants dynamic content but you have to read something first? Start the read now and immediately go back to waiting for another work item in case you could be doing something else in the meantime. When it completes, the OS will post it and you can finish the operation: do the necessary processing, start an asynch write of the result to the socket and go back to waiting for more work.
Client wants a static file? Start the transfer with TransmitFile [microsoft.com] (it's like UNIX sendfile) and immediately wait for another work item.
The only thing you should be blocking on are locks to synchronize multiple threads. Never IO.
On a single processor machine, you might as well only have one worker thread since it should never be blocked except for lack of work: this means that nothing has to be threadsafe. The buggy PHP extensions could live in a happy single-threaded world without sacrificing any performance. Hopefully you can upgrade to better software if your server has multiple CPUs to take advantage of, or use one process per CPU.
* Apache has to have 200 threads if I ever expected that many clients to connect at one time, just in case? Can't they at least be started dynamically? No wonder it doesn't perform well on Windows. I just hope they aren't used round-robin.
From a webhosting standpoint... (Score:3, Informative)
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.