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

Comments

PHP used to be an ASF project

[gtrubetskoy]

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

[TheTomcat]

Read the thread, here

S

Re:PHP used to be an ASF project

[snipersock]

Last Sunday, if I saw the cpan.org recent news corrently, rc2 was out. Its looking to be released sooner than your probly think. And aside from your problems, I'm running loadbalanced apach2 with mod_perl2 and Mason without any issues at work.

Re:PHP used to be an ASF project

[slive]

PHP used to be called an ASF project. But that was back when being an ASF project didn't really have any formal meaning. When the ASF started to put more structure on its oversight process in order to assure that it could protect its code and committers, it was decided that the PHP project didn't want ASF oversight, and there was an amicable separation.

Re:PHP used to be an ASF project

[iamlucky13]

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

[JamesOfTheDesert]

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

[Matt Perry]

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.

Re:PHP used to be an ASF project

[Ath]

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

[killjoe]

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.

Re:PHP used to be an ASF project

[Taladar]

My personal opinion is that PHP should start again, like Microsoft often does.

You misspelled "seldom"

Re:PHP used to be an ASF project

[osu-neko]

I've had the same sort of virtual host problems with PHP, except under Apache 1.3.

Re:PHP used to be an ASF project

[Bert64]

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

apache2 is essential for Windows

[hey]

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

Re:apache2 is essential for Windows

[Anonymous Coward]

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

[einhverfr]

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

[KilobyteKnight]

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.

Re:apache2 is essential for Windows

[Randolpho]

Anyone who windows these nutz is joking.

Re:apache2 is essential for Windows

[beaverbrother]

Anybody still running Apache1 on Windows is nuts. I think a better way to phrase it is: Anybody running Apache on Windows is nuts

Re:apache2 is essential for Windows

[rabbit994]

Actually, Windows 2003 IIS is quite nice. I know I'm going to get flamed and probably modded down but if your stuck on Windows 2003 (in particular) IIS 6 > Apache. Note, I've tested PHP on IIS 6 over Apache with PHP. IIS 6 was faster, more secure (assuming patched) and used less CPU. No, I didn't do any official study, that's was my findings personally. I found people who bitch about IIS 6 have either a. not used it or b. Are poor Windows admins or maybe both.

Re:apache2 is essential for Windows

[iamlucky13]

Anyone who wants to keep this joke going is nuts.

Anyone who is nuts will keep this joke going.

Re:apache2 is essential for Windows

[jd]

Apache runs anybody on nuts through a window.

Re:apache2 is essential for Windows

[Evil Grinn]

Anyone who wants to keep his nuts will use Apache2.

Re:apache2 is essential for Windows

[Evil Grinn]

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.

Re:apache2 is essential for Windows

[khendron]

Anybody reading this far is now nuts.

Re:apache2 is essential for Windows

[kayen_telva]

Apache can run farther on nutz than windoze.

Re:apache2 is essential for Windows

[Foolhardy]

True, NT does favor threads vs processes as they are much lighter, but even more than that, NT favors a very small amount of threads running as asynchronous workers. NT inherited the heavily asynch IO model from VMS.

On NT, instead of creating 64* threads (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. 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 (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.

FUD in it's purest form ...

[Sonic McTails]

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

[Raxxon]

This was the major reason that PHP has been said not to be used with Apache2. It has NOTHING to do with Apache, it's potential security issues with PHP and some non-thread-safe **EXTERNAL** libs. 95% of it is security related issues. If you're willing to pay attention to your server (like all good admins are supposed to do) there's no real problems that I've seen.

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

[Bruce Perens]

So, why don't they put a lock around the PHP interface to those libraries? Or why don't they make thread-safe successors of those Free libraries that, presumably, they do have the power to edit?

Bruce

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

[Matt Perry]

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.

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

[JabberWokky]

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

[Raxxon]

PHP to rewrite bzlib? zlib? OpenSSL? MySQL? MSSQL? Oracle?

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. :p

It's a threading issue

[Bruce Perens]

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

Re:It's a threading issue

[Anonymous Coward]

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.

Re:It's a threading issue

[TheTomcat]

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

[markv242]

FYI, PHP compiled in CGI-mode completely eliminates the threading issues that PHP has with Apache 2, and allows you to continue to use Apache in worker mpm mode (which is, by far, the most efficient -- think orders of magnitude better performance on the same hardware).

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

[Bruce Perens]

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

Re:It's a threading issue

[EnronHaliburton2004]

And then you lose much of the benefit of Apache 2.

I don't understand.

Are the PHP developers not recommending Apache 2 because it is harmful to upgrade? Or are they not recommending Apache 2 simply because there really aren't any benefits to upgrading.

Upgrading (and rolling back an upgrade) Apache has always been pretty simple, and it's pretty easy to have a 1.3 Apache running alongside an Apache 2.0.

Re:It's a threading issue

[pthisis]

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

[Bruce Perens]

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

[rho]

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.

As I recall, an old benchmark showed that a 486 running Linux and Apache could saturate a T1 serving static content. I'm not sure what benefit a "static content" metric has to any discussion concerning modern Web technologies. If static content is your problem, there are gobs of Web server solutions, such as that old kernel HTTP server, whatever it was called. Threading, pre-fork, blah blah blah--it's all gobbledy-gook when you're talking serving plain-jane HTML files.

I think Apache solved the problem too well with the 1.3 branch. It's a robust, fairly clean solution to serving Web content, either static pages or some degree of dynamically-created Web application. If you need to do either, or somewhere in between, Apache 1.3 is a decent solution. The way I see it, if Apache wanted to differentiate their 2.0 branch, they could have gone either one or both of these routes: 1) build it with the intention of catering to the Web application market; or 2) build it with the intention of catering to the Web hosting business.

With 1), the core problem of dynamic Web sites is the glue between a database and the HTTP server. Quite a lot of Web sites would be equally well-served by a lightweight HTTP server on top of a relational database. Something like Oracle's IAS, but... not. If Apache 2 could offer something like that, then they would have something to offer Web application developers. (And, incidentally, create a new market the way Tomcat/Java servlets did and thus a stable base of users.)

With 2), there's a lot of work done by companies such as PSoft and Ensim to provide a facility for hosting several Web sites from a single IP address, and allowing those Web sites to have some control over their site. If Apache 2 could offer some method for improving this situation--"how" I leave as an exercise for the reader--then they would have something to offer hosting companies. (And, incidentally, create a whole raft of adopters as most people who buy Web space at a hosting company for $29.95/mo, or whatever, don't give a fig for what HTTP server is running behind their site.)

As-is, Apache 1.3 can do both 1) and 2) good enough, and as we all know, good enough is good enough. Everybody will eventually move to 2.0, if only because RedHat stops supporting 1.3 in their up2date utility. I don't think there will be a mass exodus to Apache 2.0 for any technical reason, like the movement we see today towards FireFox from IE, because Apache 1.3 isn't a complete piece of shit. It's pretty good, as a matter of fact, and that Apache 2.0 isn't exactly bursting with new, revolutionary ideas that can change the world, the change will come slowly and quietly, until one day you'll sit up in bed and wonder, "Whatever happened to Apache 1.3?"

Re:It's a threading issue

[pthisis]

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.

Multi-thread...

[allanw]

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

No need to switch ...

[Anonymous Coward]

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

[garcia]

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.

Re:No need to switch ...

[rbowen]

Right ... and, like I said (I thought, pretty clearly) I'm not saying that everyone should switch. I'm merely asking for the PHP website to stop discouraging migration for those folks who do have reasons for doing so.

I know, suggesting that Slashdot might be misinterpreting my words is close to heresy ... ;-)

Re:No need to switch ...

[Saeed al-Sahaf]

I run a FreeBSD server with Apache 1.3.33

One 3 too many, and one 7 short of 1337! Work on it. Maybe install Slack or something...

Re:No need to switch ...

[Khazunga]

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.

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

[Mr Guy]

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?

Why are there two??

[jdavidb]

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??

[jdew]

From what I've gathered, Apache2 is a reimplementation and 1.x is just in maintenence mode (security fixes etc)

Re:Why are there two??

[Anonymous Coward]

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 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??

[rbowen]

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??

[jdavidb]

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

[Daeron]

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

[cybermint]

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!

[Anne Thwacks]

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

What is supposed to be the problem?

Re:Nobody told me!

[Anonymous Coward]

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.

PHP and Apache 2.0 seem fine

[Dr.Dubious DDQ]

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

Using PHP on Apache 2.0 right now.

[suso]

I'm using PHP on Apache 2.0 production servers right now. Honestly, I can say that PHP is more at fault for its own problems. I think that having lots of configurable options for a programming language is a bad idea. It leads to applications working on one installation of PHP, but not another. Administrators who enable things like safe_mode and turn off register_globals on shared servers are made fun of by ignorant programmers who don't understand what safe_mode is for and its usefulness. I have encountered all of this.

The one thing that I wish PHP would take advantage of in Apache 2.0 is the ability to run code as a user other than the web server. Every time I bring this up with the PHP developers, nobody really runs with it. A feature like this would make PHP much better in shared systems and prevent people from having to do weird things to ensure security. I guess PHP is not that great for shared systems right now.

Re:Using PHP on Apache 2.0 right now.

[cliveholloway]

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

Re:Using PHP on Apache 2.0 right now.

[g0at]

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

Re:Using PHP on Apache 2.0 right now.

[sean_gabriel]

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)

Re:Using PHP on Apache 2.0 right now.

[drew]

I think that having lots of configurable options for a programming language is a bad idea. It leads to applications working on one installation of PHP, but not another.

i agree completely- i have had no end of problems with one of my co workers who continually writes code that requires register_globals and magic_quotes_gpc, no matter how many times i ask him not too. and even though i have told him that those options will be turned off for any new system that i set up, he still asks me why his code is breaking every time i set up a new site...

what's really annoying is that this guy is the most paranoid guy i've ever met when it comes to securing servers against remote shell exploits. apparently he couldn't care less whether he is writing exploitable web sites, though...

Re:Using PHP on Apache 2.0 right now.

[Rich0]

There simply shouldn't be a php.ini. Or if there is one it should be along the lines of the config files other languages use to set up DNS resolution, library load paths, etc.

Imagine if every system had a gcc.ini, a glibc.ini, and so on?

Imagine if allow_pointers, disable_switch_statement, and short_circuit_boolean were system-wide global settings?

Good luck getting enough compatible software on a system to even boot it!

A language should have defined default behavior. If you want to modify the default behavior, this should be done via a directive in the source code of some sort. Then each program can have its own settings. If you have a webserver with 100 programs on it, and one requires register_globals, why enable this for every piece of source on the server?

Slashdot uses Boa for images

[Tim Macinta]

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

Making the sqitch

[haplo21112]

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

No its not worth it,

[Jason Hood]

Stick with kernel 1.3.79 and Apache 1.1 just to be "safe".

What extensions?

[bucky0]

Is there a list somewhere of extensions that are known to be non-thread safe? Or do I need to just test them one by one?

Re:I have no reason to switch.

[snipersock]

Yeah, be very affraid of new technology, it could be better and force you to upgrade.

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

[Bruce Perens]

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

apachetoolbox supports the 1.x apache

[phildog]

For me the reason to use apache 1.x with PHP is very simple. That is the only configuration that is supported by ApacheToolbox.

I've done the roll-your-own apache/mod_perl/mod_php/mod_etc.etc.etc... thing before. I'd love to have those hours of my life back. So if the Apache foundation really cares about evangelizing 2.x why don't they create something as powerful as ApacheToolbox that actually works with 2.x?

Re:Homegrown apps are one thing...

[Bruce Perens]

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

How many hits?

[dsb3]

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.

I think they're right

[jeif1k]

PHP prides itself on being an easy-to-use language for web applications, and it succeeds. Unfortunately, Apache hasn't become any easier to install and configure between 1.x and 2.x; in fact, if anything, I think it has gotten overall worse. That's why Apache 1.x is a better match to PHP than Apache 2.x. If Apache wants 2.x to be a better match with PHP, then Apache needs to address the problems the PHP community sees with 2.x.

Personally, I'd like to see more server alternatives to Apache anyway. I think there should be a handful of FOSS web servers capable of hosting PHP, web servers that make different kinds of tradeoffs between performance, security, and ease-of-use. The huge market share that Apache has, from my point of view, is a problem, just like the huge market share that Microsoft has in other areas.

Re:I think they're right

[ivan37]

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.

Not up to us ...

[A nonymous Coward]

How much longer can we keep this joke going?

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

Don't see the issue with Apache 2 and PHP

[web_boyo_in_sac]

I've been using Apache 2 and PHP for almost a year on a pretty high traffic system and it works fine. But I don't do any image work or odd compression or scientific formulas so I don't compile some libs in. I think the Zend guys need to actually break down which libs shouldn't be run with Apache2

Apache Tweak.

[DarkHelmet]

I've been running Apache 2.0 for the past year or so, without any problems whatsoever.

The problem is running apache in WORKER or PERCHILD MPM modes. Those are the ones that are using threading.

What I'd recommend to anyone who wants to have a robust, fast apache implementation is to do the following:

• Setup a version of Apache on port 80 that runs worker MPM. Use this version for serving images and html files.
• Setup a separate version of apache (port 9000 or whatever) on prefork that runs all CGI / PHP based stuff.
• Proxy requests matching PHP / CGI / etc to the port 9000 version of apache.

There you go... performance increase for 75% of serving requests.

P.S: Avoid perchild at all costs!

Um ... that's not quite what I said

[rbowen]

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.

FUD is logical.

[Spy der Mann]

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.

Re:FUD is logical.

[Qzukk]

no one has dared to make a COMPLETE TEST of PHP running with Apache2, explaining which PHP modules fail and why.

This is what I want to know. Which modules use libraries that are threadsafe (or have threadsafe versions)? Which modules are known to crash the thread?

I build php here with postgresql as the only additional library over whatever the default modules are (and I have found threadsafe patches for libpq). Is having threadsafe libraries enough?

Re:Frontpage

[slacker775]

If Frontpage extensions are not available for Apache 2, that sounds like an extremely compelling reason to use 2.0! Frontpage extensions should never be used in any way, shape or form IMHO. I suppose they can actually be secured in some fashion, but I've never encountered any organization that succeeded at it. These are always backdoors into web defacements and depending on the architecture, the organization itself.

Much the same as...

[yoshi_mon]

In large projects there are often people who have production systems that would incur large costs if they were forced to do a major rev upgrade.

Of course before OSS this was never an issue as people didn't have a choice but as people now do, thanks largely in part to the ability of OSS project heads to put a few "free" developers on a older rev for maintenance, large OSS projects often maintain older revs for the sake of the users..

You really need look no further than the Linux Kernel to see another example of this in action.

Efficiency is not entirely a web server function

[Bruce Perens]

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

Stop picking on PHP

[Duncan3]

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)

Re:Stop picking on PHP

[cant_get_a_good_nick]

My belief is that PHP is fine under threads, a lot of the third party stuff is unknown (can be read: probably will break) and the PHP guys don't want to bother with broken 3rd party stuff.

This kind of misses the point. The assumption "why bother with apache 2.0 if it doesn't run in multi-threaded mode" misses all the cool things that have gone into apache 2.0 outside of the threading models. I'ts a lot saner, and has cool things like chaining (output of CGI can go through SSI) and a million other things. The PHP guys should just say "run it in the old MPM mpde and have fun" which is I think the real sticking point.

Re:Frontpage

[Jokkey]

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.

Windows doesn't seem to have this problem

[Anonymous Coward]

The horror of actually making solid software; nobody's upgrading.
Maybe Windows knows what it's doing after all.

Re:Apache 2.x memory model is bizarre

[Bruce Perens]

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:Apache2: The only choice for Win32

[JimDabell]

I'd gladly ask the Apache and PHP guys to fix their "nobody" user problem, and start PHP with separate accounts.

Apache 2 threaded MPMs can run different vhosts under different users, so this has been fixed for over two years. If PHP was thread-safe, you wouldn't have a problem, but as this story highlights, PHP doesn't play nice with threads.

Re:PHP and Subversion

[DarkBlack]

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.

Re:Homegrown apps are one thing...

[Evil Grinn]

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.

Which, as I have remarked earlier, is a sympton of PHP never having been designed to run on Windows.

Maybe there's an opportunity for someone to get famous by writing PHP interpreters in both Java and C#, and then they can sell it to all the PHB's out there who can't decide whether to go with J2EE or .NET. That should take care of the threading issues, although it would almost certainly break existing extensions written in C/C++. I am only half kidding.

OT: Great sig

[ConceptJunkie]

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.

mod_lisp

[stesch]

Well, mod_lisp was a good reason to stay with Apache1. But there was some work done on the Apache2 version of the module, so it should be all clear to upgrade to Apache2, if you need it for more than just serving to your lisp image.

The bloat is BEFORE sendfile()

[wtarreau]

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

The problem with apache performance lies in everything that it executes *before* sendfile() is called. Sure you'll be able to serve *ONE* static file at wire speed, but when it comes to serve *many* files per second, the initial overhead puts the foot on your way.

And unfortunately, apache is not good either for serving large files because of the important memory (and scheduling) cost of each concurrent thread (or process in case of preforked). Apache is good as an application server, not as a static content server.

willy

changes how things are done, and not what is done

[PhYrE2k2]

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.

PHP suExec is available.

[kbahey]

The one thing that I wish PHP would take advantage of in Apache 2.0 is the ability to run code as a user other than the web server. Every time I bring this up with the PHP developers, nobody really runs with it. A feature like this would make PHP much better in shared systems and prevent people from having to do weird things to ensure security. I guess PHP is not that great for shared systems right now.

suExec for PHP is available. My ISP has switched to PHP suExec several weeks ago. I noticed that something was different when cookies was not set properly, and the PHPSESSID was set in the URL (ugly, so I noticed).

This facility makes PHP runs as the user him/herself, instead of the Apache user (just like you wanted). This is a more secure environment for sure.

You need to have a php.ini file with the parameters you want, in your public_html directory, to override the defaults (e.g. how the PHPSESSID is handled, by a cookie, or in the URL, how long a session is valid for, ...etc.)

Rewriting libraries

[Bruce Perens]

What we are asking for in these rewrites is for what are presently global variables to be made part of a structure that is allocated per-thread by a library call and then passed to all calls to that library as an argument. You don't have to use any magic POSIX thread-local memory stuff to do this, and it's portable. No software logic need change. If this point is made effectively to the maintainers of these libraries, they'd do it.

If the thread gets destroyed or exploited outside of PHP in one of these other libs, HOW is that PHP's fault?

Some programs do unwind context on catching a signal. Especially those that provide an exception mechanism.

It still seems to me to be an architecture issue.

Bruce

er, no...

[MenTaLguY]

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.

PHP-as-CGI doesn't work on many web servers

[Luke Mewburn]

Except PHP-as-CGI relies upon a "non standard" CGI variable (SCRIPT_FILENAME) to operate correctly, and many non Apache/IIS web servers don't provide that variable. Thus, PHP doesn't work under them.

I worked out this problem a while ago, submitted bug 28227 with fix, and it's been sitting in the PHP bug database doing nothing for months. Not only that, but many similar bugs (without fixes) were closed prematurely by the PHP team under the incorrect assumption that the submitter's system was misconnfigured, as opposed to PHP being buggy...

this is untrue.

[vena]

from the docs:

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

Apache2.0 = XFree86

[mnmn]

Fights between opensource projects are always sad. Part of the openness is use it however you like... recommendations are opinions. ASF isnt quite blocking PHP yet, but things can go wrong as we've seen in the case of jboss and xfree86.

Whats stopping anyone from uniting php and apache1.3 and packaging them together for each platform the way sqlite was incorporated into php? They go well together, makes alotta sense to be the same project.

From a webhosting standpoint...

[bedessen]

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.