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."

PHP used to be an ASF project

I should probably be noted that PHP used to be an official Apache Software Foundation project until it was mutually agreed to end this relationship. I have no clue as to what the underlying reasons were and as an ASF member myself would rather not speculate on this. See ASF Board Meeting Minutes [apache.org] for Feb 2004 (section 5.G).

P.S. Apache 2.0 is great and there is no reason not to use it IMO.

Re:PHP used to be an ASF project

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.

Re:PHP used to be an ASF project

No, the PHP folks specifically tell you not to run PHP with Apache 2.0. It is in their FAQ on their website.

Re:PHP used to be an ASF project

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.

this is untrue.

from the docs: [php.net]

Do not use Apache 2.0.x and PHP in a production environment neither on Unix nor on Windows.

Re:PHP used to be an ASF project

But then again I'm a perl developer and php is obsolete to me.

Hello, pot? This is kettle ...

Re:PHP used to be an ASF project

This would be a huge headache for people who provide webhosting tho..
For instance, i am unable to upgrade my server to php5 because many customer code won't run correctly on it.. But before too long, we will have customers demanding php5 because their code doesn't work on 4..

Re:PHP used to be an ASF project

IIRC, it was a license issue. The AFS wanted the PHP project to switch to using one of the ASF licenses [apache.org] while the PHP folks did not. PHP is still listed as a sister project. It's just not under the official ASF umbrella.

apache2 is essential for Windows

Anybody still running Apache1 on Windows is nuts.
Apache2 works way better on Windows.

Re:apache2 is essential for Windows

Anybody still running Apache1 on Windows is nuts. Apache2 works way better on Windows.

Anyone still running Windows is nuts ;)

Re:apache2 is essential for Windows

Anyone who eats nuts is Windows!

How much longer can we keep this joke going?

Anyone who wants to keep this joke going is nuts.

OT: Great sig

The problems with Christianity and D&D are essentially the same: too many people RTFM, but don't comprehend it.

Great sig!

The good thing about Christianity is that the DM is much, much better. Or at least more consistent.

The bad thing is that He can't be bought off with a six-pack of Dew and a pizza.

The good thing about D&D is that the DM is usually your friend and will try to make it so you have fun.

The bad thing is that the DM can give you millions of gold pieces, +8 everything and make you king of world or even a god, but you still gotta go to work/class on Monday morning.

Not up to us ...

How much longer can we keep this joke going?

Talk to Microsoft, it's them what's keeping the joke going.

Re:apache2 is essential for Windows

However, the issue is that many PHP extensions are not threadsafe. This becomes an issue on Windows because the default MPM is multithreaded, while the default MPM for UNIX is multiprocess.

Re:apache2 is essential for Windows

However, the issue is that many PHP extensions are not threadsafe. This becomes an issue on Windows because the default MPM is multithreaded, while the default MPM for UNIX is multiprocess.

It all goes back to Windows NT being designed from the beginning to enourage the use of threads, while Unix always favored multiple processes.

FUD in it's purest form ...

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.

Re:FUD in it's purest form ...

Several of the libraries are commercial software interfaces. I have no idea how many (if any) are unsafe, but they are things like interfaces to Oracle, commercial layout software, etc.

As for putting a lock around them, I'd imagine that when that happens, it would be considered thread safe *except*...

PHP has a user contributed library system similar to CPAN called PEAR. Some of the libraries in PEAR aren't threadsafe... and even if somebody went through and updated them, next week there will be several new one that are not threadsafe.

Now, all of this would be moot if there were a compelling reason to push to Apache2. The impetus would be there to do the work. But, right now, the last of the 1.x series is just as stable and performs as well as Apache2. That means that there's simply no reason to do the work, and Open Source doesn't like to do unnecessary work.

When there is a benefit to the ongoing work necessary to make it and *keep* it threadsafe, it will likely be done.

--
Evan "And yes, I realize the irony of saying how Open Source works in this reply"

Re:FUD in it's purest form ...

Because v2 is more powerful. Filter chains for one. You can have the output routed through various modules and even shell commands before it's served up to the user. For example, if you want the output of a CGI to then go through server side includes expansion, then gzipped and served to the user. Apache 1.x doesn't have that kind of flexability.

It's a threading issue

Either PHP itself, or many PHP applications, are not written to deal with the multi-threading offered by Apache 2.0 . So, it seems, you will do best if you install one of the less optimal threading models. And then you lose much of the benefit of Apache 2.

Apache 2 and a recent Linux kernel come pretty close to the theoretical limits of the hardware when it comes to serving static content. It just loafs along while saturating whatever net connection you give it. It's worth trying out.

Bruce

I'm sorry Bruce, you'll have to come back later.

It's not nearly late enough in the thread for someone respected to post correct, non-inflamatory, rational information.

You're going to stop all the foaming at the mouth, and who wants a half-frothed troll this close to Christmas?

Re:I'm sorry Bruce, you'll have to come back later

It's OK because I didn't read any of the articles linked to in the Slashdot story before posting. Thus, I maintain the proper level of ignorance for Slashdot.

On the other hand, I had looked at the problem reasonably hard when choosing supported software for UserLinux, so I did know something about the problem. So perhaps that disqualifies me.

Bruce

Slashdot uses Boa for images

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.

Quite true. I've improved the performance in the past of a very high traffic website by switching what content I could from Apache to Boa. Boa performed substantially better than both Apache 1.3 and 2.0. If you need further evidence, look at the HTTP response headers for one of Slashdot's own images [slashdot.org] - they are serving images using Boa instead of Apache for a reason.

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.

Efficiency is not entirely a web server function

For most web servers on Linux, once the server has figured out what static file to send, it calls sendfile() and the rest of the work is entirely in the kernel until the file has been transmitted. On certain network cards, sendfile() has the property of being able to DMA from the disk to the network card without intermediate buffers. At least for big files, this is probably running very close to the hardware limit. For small files, the server efficiency is more of a factor.

Bruce

Re:Homegrown apps are one thing...

I suspect, and here I'm out on a limb, that it's a fundamental architecture issue. PHP simply did not have global thread-safety as a design goal. And thus it could be difficult to remedy at this late date, especially if it's to be done without breaking things.

Bruce

Re:It's a threading issue

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

Re:It's a threading issue

No problem with the respect, this is an area in which I don't have tremendous expertise. But I submit that if PHP itself is in charge of its interface to a non-thread-safe library, it can put a lock around calls into it - effectively single-threading each library and that would perform at least as well as going to a less efficient threading model for apache, and potentially better depending upon where contention happens. And given that this is Free Software, thread-safe successors of those libraries can be developed.

Bruce

er, no...

Kill-9ing does not always clean memory, open files, sockets, etc.

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.

Re:Apache 2.x memory model is bizarre

Consider that this could be a speed vs. space tradeoff. They are inefficient in terms of memory use. However, it's nice to have memory that is private to a thread such that only that thread accesses the entire memory page. That means that the caches and the TLBs don't invalidate as often because some other CPU has touched the data. Remember that in a multi-processor system the cache and TLBs have to watch what is happening on the bus, and invalidate themselves when they see someone else do a write to some data that they hold. Given that we have really fast processors and slow memory, this can get expensive.

Bruce

Re:It's a threading issue

It's because there are potentially random problems because of two threads writing the same data at the same time. Code that depends on the value of a global variable not changing from one line to the next might break. Imagine that you increment a variable and then assume that its value is one greater than before, but it's really two greater.

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:It's a threading issue

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).

Re:It's a threading issue

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.

No need to switch ...

I run a FreeBSD server with Apache 1.3.33 and PHP 4.3.10. When I was upgrading it a week or two ago to FreeBSD 5.3, I thought about making the switch to Apache 2.0. But then I thought ... What is that going to bring me?

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.

This, I think, is the primary reason why people aren't going to Apache 2.0 in droves, not the PHP team's "FUD".

Re:No need to switch ...

I suppose it depends on what you use the machine for. Linux isn't ready for the desktop so I don't run a GUI on it. Thus I really have no latency issues running maild/httpd/sshd/etcd.

:-)))) I'd moderate you funny if I hadn't commented yet. My desktop is linux for three years now.

Hint: Don't wait until the media says linux is desktop-ready.

Why are there two??

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.

Re:Why are there two??

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.

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'.

Re:Why are there two??

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.

Re:Why are there two??

I have no problem with that policy at all. But there is nothing at all on the front page to answer the question "Which Apache version should I use?" Even if the answer is not a simple "Use 2.0" or "Use 1.x," there needs to be answers to "Why would I want to use 2.0" and "Why would I want to use 1.x."

I have been interpreting the continued maintenance of the 1.x line for years as a statement that 2.0 was not ready for prime time. I'm pretty sure this was the case at one time. The website needs to just come right out and say, "If you are starting with Apache for the first time, please use 2.0. The 1.x branch continues to be maintained for existing users who need to remain with an older version." Couldn't that at least make it to the FAQ?

PHP and Threaded Apache

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.

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) ... is the fact that PHP keeps continuously crashing your httpd-processes.

Switching to the prefork MPM makes everything rock-solid again ... but looses the benefits the threaded-MPMs offer.

If PHP could actually solve their problems with running in a threaded Apache-2 ... i would jump right on it :)

Again .. 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 ...

Well worth the upgrade

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.

Nobody told me!

I never knew there was a problem - I have three mission critical servers (telecomms billing) running PHP5 on Apache 2, and nothing seems to have gone wrong in 12 months of 24/7 operatio