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."
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.
Anybody still running Apache1 on Windows is nuts.
Apache2 works way better on Windows.
So there you have it PHP sucks in comparison to perl, because some guy on the internet says so. Now aren't you glad you stuck with your arcane-obfuscated-gibberish parser?
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.
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
Bruce Perens.
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..
Move along, nothing to see...
"Who are in control, they are not in control of anything - they don't even control themselves!" - Glen Beck
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".
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.
If Apache wanted people to move to 2, they should provide benefits that make people want to go through the effort to move.
I've been using php 4 and Apahace 2 for a long time on my web servers. They're not high volume servers, but I've not had problems.
I can't remember when Redhat started using Apache 2, but I've been using it as soon as they included it into their packages.
Is this an issue that would resolve itself as Linux Distributions include Apache 2 and the # of Linux servers increases. As you have a higher volume of Apache 2 servers out there, it will tip the balance toward a friendlier attitude between PHP and Apache 2?
--
Brandon Petersen
Get Firefox!
Seems to work fine here.
Poof.
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?
Never confuse volume with power.
A) yes, Apache 1.3 is solid.
B) I have no requirement to switch.
C) If A & B are true, I don't recommend 2.0 as it is NOT as tested as 1.3.
Can anyone point me to a succint explanation of why there have been an Apache 1.x line and an Apache 2.0 line for years? This to me has always seemed like an implicit statement from the Apache people that I should not yet move to 2.0.
I checked the front page of Apache and there were release announcements for the latest version of both lines. Neither announcement carried a statement indicating when you should use it over the other. The front page does not appear to link to anything addressing the issue, and the FAQ does not appear to handle it, either.
Secession is the right of all sentient beings.
Who can specifically give me a reason to switch from A1 to A2 if I'm using PHP? Not that I have control over it on my ISP, but I'm curious as to what A2 adds that I should need, independent of developing in PHP.
For the record, I'm still using Win2k and Office97 @ home because I see no reason to upgrade. I have XP @ work, and it's great, but it's not better enough for me to care.
I agree with the link in the second article, though, that the PHP documentation shouldn't single out A2 unless it also notes compatibility problems with other OS/WS combinations.
And it wasn't made clear, what is the reason that PHP doesn't like multi-threaded mode? It suggests that the programs/libraries that PHP utilizes are not thread-safe, but if PHP is itself multi-threaded, why does it make a difference?
I'm a little ticked off that news like this makes the front page, yet release of mod_perl 2.0 years in the making, on Dec 12, is yet to be mentioned. I am more than certain that someone must have submitted a story on it in the Apache section.
I've been migrating several live production sites and adding new sites to a box with PHP 5.0.3 and Apache 2.0.52. The previous setup was rock solid Apache 1.3.x and PHP 4.x. I started the migration with the lowest traffic sites and plan to slowly move up to higher traffic sites. So far there have been no issues.
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
When IIS 6.0 is more secure than Apache 2.0, thats when I refuse to use Apache.
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.
Learn you damn /. jokes, nube.
What is supposed to be the problem?
Sent from my ASR33 using ASCII
The question is, is there a plan to resolve this threading issue in the future?
If not, then you can either run Apache2 with the pre-fork or just accept restarts or run Apache1.x.x
If it will be dealt with then this isn't much of a problem long term. It's just short term growing pains.
With that said, I think the position on Apache 2 should be as accurate as possible so that new users can pick either version.
As mentioned (probably more than once by now), the only issue is some non-thread-safe libraries that PHP can link to. Configuring Apache to run with the "Prefork" MPM solves this problem (by running with the same model as Apache 1.x did).
I see no reason so far to discourage use of Apache 2.0 with PHP other than vague "well, I heard from some guy that he tried it and it had some kind of problem" sort of complaints. Personally, I like the fact that Apache 2.0x has mod_ssl and mod_deflate (/mod_gzip) as part of the codebase, so I no longer have to compile and install them separately...
Hacker Public Radio is our Friend
Sounds like PhP is trying to manipulate the behavior of the Apache group.
If the issues are not substantive then why the big hulabaloo?
Religious wars only serve to speed up entropy in the system...
Lodragan Draoidh
The more you explain it, the more I don't understand it. - Mark Twain
...right here.
It's been serving a decent amount of traffic for quite a while with no problems...
The Army reading list
Isn't frontpage support the other major reason to stick with 1.3? I don't believe it is available for Apache 2.
A lot of "Web Designers" seem to expect the frontpage extensions to be available.
it must be useless for anyone who wants php. That seems to be the main theme of these posts. Just because a feature doesn't provide much to a pure php setup doesn't mean that there aren't people who want to run php as part of their site but still need some of what apache 2 offers. Seems pretty short-sited.
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.
and here i was, thinking that the open source community is the one place that's devoid of politics.
sigh
I know for a fact there are issues with Apache 2.0 and PHP. There are a few functions that do not work correctly, and their answer in the PHP fourms is to go back to Apache 1.x. Grrr.....
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
Apache2 with a prefork MPM still way outperforms Apache 1.3 with PHP and is rock solid. Too bad this is not the default on Windows.
If you use the worker or Win32 MPM, you are stuck with using CGI.
LedgerSMB: Open source Accounting/ERP
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.
Stick with kernel 1.3.79 and Apache 1.1 just to be "safe".
Are you intolerant of intolerant people?
I have worked in the past with Rich Bowen, in his mind everything he works on is perfect and people should not fear. If the php people say, don't use Apache 2 yet, then let's listen to them.
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?
-Bucky
In China, Worker-MPM race condition is always positive.
The underlying threading problem has little to do with PHP, and absolutely nothing to do with PHP applications, but libraries to which PHP links (libmysqlclient, libpdf, libmcrypt, etc etc etc). It's these third-party libraries (over which the PHP developers have no control) that cause Apache2 to be unstable in the various threading modes (prefork works fine, but is just not officially supported).
:-)
Sounds exactly like the wonderful world of Windows programming
If you have a win32 server and want to put a WAMP (Windows/Apache/MySQL/PHP) stack for your website, Apache2 is the only choice. Apache 1 isn't recommended for win32 servers...
so far Apache2 is working perfectly. And I really like the new syntax for add-on modules.
Offtopic: *HOWEVER*, If we want to take things commercial grade, I'd gladly ask the Apache and PHP guys to fix their "nobody" user problem, and start PHP with separate accounts. It's hideous for security having a user with access to all the subdirectories. Our website in a shared host got defaced a month ago because of this "tiny detail"
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
Bruce Perens.
1. Why shouldn't I use Apache 2 in a production environment?
The following answer is based in this modified excerpt of a mail by Rasmus Lerdorf.
Apache 2 is a complete rewrite and a complete architecture change from Apache 1. It is not like going from PHP 3 to PHP 4 or from PHP 4 to PHP 5. There is a lot of code that is common, and certainly the base architecture of PHP has not changed for years. So comparing Apache 1 vs. Apache 2 to PHP 4 vs. PHP 5 makes no sense. The architecture has been proven over the years and the code, while somewhat unwieldy in places, is a known entity. PHP from the very early days was designed against this basic Apache 1 architecture and works extremely well running under it.
The major feature that draws people to Apache 2 is threading. On Windows where most basic libraries are, and must be, threadsafe, Apache 2 does actually make sense and it would be good to work out the kinks on that platform. However, on UNIX there are a lot of basic libraries where thread safety is an unknown. And this is not about PHP extensions, it is about 3rd-party libraries underneath PHP's hundreds of extensions. Whether any one 3rd-party library is threadsafe is really hard to determine. There are a lot of variables involved, including which OS, which version of the OS, which libc, which version of that libc and on some platforms even the compiler flags used to compile these things. And to make it even more fun, tracking down a thread safety problem is damn well near impossible. Hundreds of people may well state that Apache+PHP+ext/foo works perfectly for them, but maybe they are only getting about a million hits a day. Then another user comes along who gets 100 million hits a day and uses a fast dual-cpu machine and everything blows up because now suddenly the window for some tiny race condition has been made much larger due to the faster cpu speeds, the second cpu and the higher frequency of requests. And the bug report we get from this user will be something along the lines of:What can we do about these?
There are a number of (fixable) technical reasons Rasmus does not think Apache2+PHP is a good idea in a production environment, but setting those aside it really boils down to one simple concept:
PHP is glue. It is the glue used to build cool web applications by sticking dozens of 3rd-party libraries together and making it all appear as one coherent entity through an intuitive and easy to learn language interface. The flexibility and power of PHP relies on the stability and robustness of the underlying platform. It needs a working OS, a working web server and working 3rd-party libraries to glue together. When any of these stop working PHP needs ways to identify the problems and fix them quickly. By making the underlying framework more complex by not having completely separate execution threads, completely separate memory segments and a strong sandbox for each request to play in, a feet of clay is introduced into PHP's system.
Using the prefork mpm with Apache 2 to avoid the threading is possible, and yes using a standalone fastcgi mechanism to avoid the threading, too, but then defining characteristic of the web server of choice are avoided. At this point in its development, Rasmus still maintains that one is better off simply sticking with Apache 1 for serving up PHP pages with the one caveat that Apache 1 sucks pretty badly on Windows.
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?
slashsearch.org - slashdot search. powered by google.
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.
I think the Apache Foundations problem isn't with people who don't want to upgrade (if it ain't broken...) but with PHPs recommendations against using Apache2 with PHP.
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.
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.
Is there any way for Apache 2 to throttle bandwidth for Virtual Hosts? I know the mod_throttle and mod_bandwidth modules for Apache 1.3 were extremely popular with people hosting multiple sites. Is there any support for this feature in Apache 2?
--It's Pimptastic!--
How much longer can we keep this joke going?
Talk to Microsoft, it's them what's keeping the joke going.
Infuriate left and right
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
Interestingly enough, the site for the Apache spokesman, on Apache 2.0, is down; while the site PHP guru John Coggeshall, on Apache 1.3, is still up.
Jason Lotito
Coggeshall seems to put it best by outlining all the new features that Apache 2 offers and then describing how they are mostly useless to people, but in most instances, to himself. Thanks. We all appreciate you determining for everyone else what features we do/do not need.
In my estimation, the PHP guys really don't care, because making PHP build safely for Apache 2 wouldn't give enough of a payoff to make it worth their while, thereby crippling any improvement over the current Apache 1.
I would think that they could at least make the build system for PHP by:
1. Mark all the thread-unsafe libraries and extensions
2. Issue a warning/stop the build if those are compiled against Apache 2
I don't think that would be terribly difficult. So, yeah, I'm going to go with "lazyness" as the answer.
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:
There you go... performance increase for 75% of serving requests.
P.S: Avoid perchild at all costs!
/^[A-Z0-9._%+-]+@[A-Z0-9.-]+\.[A-Z]{2,4}$/i
Entire Lyrics
MP3
OGG
"So once agin' it was right, but then
The lake went dry, she was gone again!
Fish started flippin' and floppin' about
Yellin' "Mercy Puff! It's a doggone drought!"
So he rolled up-gulch till he hit the lake
Of Apache fish, they was on the take
They'd built a dam that was made of rules
Now Puff was pissed and he lost his cool!
I'm sick and tired of these goldarn words!
n' laws n' bureaucratic nerds!
You're full o' beans n' killin' my town
and if you's all don't shut er down
I'll hang a lickin' on every one
of you sons o' bitchin' greedy scum!
So he blew the dam, an' he let 'er haul
Cause water oughta be free for all!"
Maybe this will give people the reason to obsolete PHP and use a real language for server-side scripting.
___
If you think big enough, you'll never have to do it.
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
Apache 2 has a non-free license, has had so many security problems in its short life its not even funny, and there are inevitably tons more waiting to be found since the new codebase is so much more complex. All this complexity makes apache work much better on windows, and gets you nothing at all if you use unix.
So, its a question of using the tried and true apache 1, with a better license and fewer security problems, or switching to apache 2 with a worse license, more security problems, and no benefits. Gee, tough call.
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.
I really don't understand why there needs to be any argument or disagreement here. If some people really like Apache 1.x a lot and don't like 2.x (whether it is justified or not), there's a easy solution: Fork 1.x and maintain it yourself. Then the Apache people can focus on 2.x and not worry about 1.x and the PHP people can choose either competing package based on which they like best.
This is similar to the whole FreeBSD 4.x vs 5.x arguments and the spawning of Dragonfly. Open Source is about choice, and different projects can live or die based on their usefulness and/or popularity.
I know there are problems in theory, but has anyone had any in practice? I've been using PHP with apache2 for quite a while, and not noticed anything weird - it would seem to be the same case for everyone else I've talked to...
I mod down anyone who says "I will be modded down for this", regardless of the rest of their comment
This isn't controversial at all. If you're doing anything remotely important with software, the question WHY should ALWAYS be asked when upgrading. Too many kids these days upgrade for the sake of upgrading, without thinking. If there's nothing wrong with your current software, and little or nothing to be explicity gained from upgrading, then upgrading is a waste of time, money, and simply a bad idea.
I don't respond to AC's.
Recommending people not use Apache 2.0 with PHP is totally different from not recommending people use 2.0, because Apache 1.x is acceptable and considered secure. Recommending not to use an upgrade requires evidence or other proof of claims of insecurity, or it *is* just FUD, while not recommending an upgrade when the old version still works (and is still maintained, including security patches) is a prudent IT management policy.
On the same note, condemning a software organization for engaging in FUD is totally different from condemning its software package as bad. We're dealing with globat IT, on which billions of dollars, and even many people's lives, depend in critical paths and essential systems. We don't make good decisions about IT choices by reducing them to "we don't like you anymore" or "you're mean". That kind of childish conflation of product criticism with personal dislike is one advantage that proprietary companies exploit in their "button-down" "businesslike" image management, competing with even the most successful open source projects like Apache. Let's get our heads together and get over it.
--
make install -not war
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.
Really, I know what I'm doing...Ohhhh, look at the shiny buttons!
Bruce
Bruce Perens.
I've noticed many times that Apache and Php will not play nicely with eachother when compiling them as static or dynamic objects.. it's always been hit or miss with versions and features to the point I went back to 1x apache.
Stop being so mean! It's not PHP's fault they can't run in a thread model. Threads have only been commonplace for 25 years, and the standard way you do things for 15.
They just need some time to catch up. Apache 2.x is light years faster/leaner/meaner then 1.x was. Oh, and PHP runs perfectly fine under 2.x, as others have pointed out.
OK, so yea, it's actually kinda sad (read: pathetic)
- Adam L. Beberg - The Cosm Project - http://www.mithral.com/
The origin of the name "Apache"
. . . and after reading up on things, I determined that:
1) for my win2k server, apache 2 is a necessary upgrade
2) for apache 2, php 4 is a safer choice
3) if I ran a *nix box, I would be using Apache 1.3 & php 5
Moderators do not post stories, they moderate comments. Editors post stories.
The horror of actually making solid software; nobody's upgrading.
Maybe Windows knows what it's doing after all.
I'm running Apache 2 and PHP 5 under FreeBSD 5.3 with no problems (that I know of...). Whats all the ruckus about?
/usr/ports/lang/php5-extensions
# cd
# make install clean
"The chief enemy of creativity is 'good taste'" -Pablo Picasso
The developers of PHP have one major, ongoing problem - they don't know the meaning of the term "backward compatibility". The last three major updates to PHP have all broken major features and applications. Apache, on the other hand, just keeps working. Given mod_perl and java, why do we need to keep dealing with PHP at all?
Comment removed based on user account deletion
I know it's widely used, but it's a pretty bullshit little language anyway. Kind of the beginner language for web coding.
Make a list sometimes. Of websites that go down completely (return some kind of an error) instead of just slowing down during a slashdotting, most of them are PHP issues. Almost every site dead from load is one spouting some "PHP process..." message.
I think this is going to become more of an issue as software projects choose to target different versions of Apache.
For instance, recently I was setting up a Subversion server for a project I was working on. It turns out that if you want to run Subversion over WebDAV/DeltaV, you are forced to use the Apache 2 series. As many have pointed out, if you try to use PHP in this environment httpd will randomly die off since PHP isn't thread-safe. When you are using Apache to write information, rather than read it, this is a very troubling issue.
Of course, this is easy enough to work around, you can either use one of the other access methods that Subversion supports, or install both versions of Apache simultaneously, placing them on different ports, or simply choose not to use PHP, however these are all workarounds, not solutions. Imagine what happens if other software takes this approach, say for example jboss, and you need to use both for different parts of your site. Suddenly, the "run both servers concurrently" approach doesn't look very attractive.
Our problem was that we have database searches that return potentially hungous numbers of records, which take up memory, which isn't given back to the system. Having lots of giant Apache processes around drove us to make the Apache process die when it was done. I forget the name of the PHP command that does this, but I recall from my testing that it didn't work with Apache 2. Does it now? or is memory usage handled differently now?
(Yes, I know the best solution would be to page the results, but that would require significant retooling of the application - long story - and I wanted the upgrade to be a simple drop-in replacement with no code changes. And we're short on resources, so proxying such requests would not buy us much.)
Exit, pursued by a bear.
How about we classify the php extensions as "thread safe" and "not thread safe". This way when I make a custom install of php, I can decide which apache to install based on the extensions I require. Does such a list already exist?
The biggest problem with PHP-based virtual hosting is that any script running has full permissions as user "nobody".
PHP SafeMode is an ugly hack fraught with security holes. The real answer is RIGHT HERE but alas, it's been dropped.
these guys have done some more work with it, and the best bet (so far) seems to be this one which (at least) has active development on it.
I LOVE the idea - from a security standpoint, this is the best news for Apache/Unix shared hosting since the invention of the password. I have a fairly busy server (about 700 active domains) and I'll be slowly migrating over the next 6 months or so to using this tool.
It works with PHP and Apache2. I just won't use any non-threadsafe libs, so no issues there.
I have no problem with your religion until you decide it's reason to deprive others of the truth.
first it says not to use apache 2.0 with php, then it says that php commnunity is promoting 2.0?
what the hell ??? screw the moderators, we need editors
Yeah!? Well in Korea, Worker-MPM race condition is only for old people!
Microsoft says that if its not digitally signed, its not safe to download.
then the user would have to force the install if the PEAR modules they plan to use are ok.
Binaries... compiled safe only.
...Silver and Black appliances don't mix.
Long live the confede.....Nevermind.
I guess trying to run subversion with Apache might be a compelling reason to upgrade since it requires Apache2...
... with no problems here)
(Running Apache2 with svn, PHP,
I made the decision to continue using Apache 1.3 simply because of the higher number of security related releases on the 2.0 branch.
Having worked for software engineering companies I can appriciate the pride and dedication to products that developers have, every developer would love you to run his latest and greatest code.
Unfortuantly on the other side of the dice when I am administering servers I appriciate stability and longer cycles between upgrades or security advisories.
I'm surprised nobody has mentioned that the Apache2 license is more restrictive than the Apache1 license, which could make for problems.
Does anyone else remember when SSHv1 was free, and SSHv2 was commercial? It took years before most machines dropped SSHv1, despite it's numerous security problems.
License issues can be very significant.
Slashdot gets worse every day... Pipedot: News for nerds, without the corporate slant
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.
You are in a maze of twisty little passages, all alike.
If there are bugs the wide spread adoption in using PHP with Apache 2.x would be more beneficial as it will resolve the bugs in a much more timly fashion.
I guess this is the joy of the world.. friction..
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.
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
The lack of simple inteligent proxies and load balancers such as mod_backhand for Apache 2.0 is a major show stopper. There's simply no large enough machine (for limited budget) that would be able to handle the load. And i find other load balancing solutions inferior.
Anyone else notice that Apache 2 seems to perform significantly better for sites which use a lot of SSL encryption?
Best /. post, ever.
Apache 2 changes CORE functionality- great! But that doesn't really affect what it does, but rather how it does it. Maybe if it implemented some new HTTP 1.2 I would get it in there... but who'd notice?
Apache1 has been tried, tested, and true and has reached a lovely 1.3.33 version, of which security patches are rare and bugfixes are also rare. Similar situation with mod_ssl. So why leave your nice warm, structurally stable house in favour of the blistering cold to try something new that has a new version for bugs and security on a much more common basis? Personally, until Apache 2 gains some serious market share, I see no reason to leave. We provide hosting- and need reliability, and can't be wasting time with constant updates (though updates are better than not fixing of course) when we could otherwise stick with Apache 1.
Apache1 does one thing, and does it well. Period. Sure there are crazy new features of Apache2, and I've tried them else. Personally, I see nothing compelling to move at this point. There are a few small 'that would be nice' features, but really nothing exciting in the way of Linux2.6, WindowsXP, etc. Even 2.6 is having slow adoption. You can only find it on workstations, because no supportive provider is about to live on the bleeding edge and leave their customers bleeding. Apache on the other hand doesn't have a place on the workstation (unless it doubles as a causal server), so in the same way, you're trying to get those folks who prefer stable releases (like Debian stable) over bleeding edge.
So why switch?
"Bad press leads to lots of misinformed morons saying stupid things about how Apache 2 is not ready for prime time." -- I guess I'm one of those morons. Personally I'm not about to replace one of the core pieces of software between us and our customers with something that hasn't proven itself to me. We've set it up in testing environments, and found that it performed similarly and didn't offer anything new we need.
when you see the word 'Linux', drink!
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.)
2bits.com, Inc: Drupal, WordPress, and LAMP performance tuning.
Very cool solutions. There seems to be a lot of ppl bitching about it that have been modded up. Someone please Mod this up so people can find out about these two solutions.
Good, since I didn't even read your post ...
Your head a splode
It still seems to me to be an architecture issue.
Bruce
Bruce Perens.
If you get perchild working, let me know. As far as I can tell from trying to use it is that it is broken (at least on linux), and no one is doing anything to fix it--I haven't seen anything in the changelogs about it for a while now, anyways.
That's OK, you're only a figment of my imagination anyway :-)
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...
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...
from the docs:
Do not use Apache 2.0.x and PHP in a production environment neither on Unix nor on Windows.
That's OK, you're only a pigment of my imagination anyway :-)
... I _hate_ that color.
I hope I'm not the acetylen-blue one
Your head a splode
Actually, I put in the wrong link. I meant to say that this is where active development is happening.
He says it works well on his modest server. I'm going to be trialling it in a production environment, one site at a time.
-Ben
I have no problem with your religion until you decide it's reason to deprive others of the truth.
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.
"Give orange me give eat orange me eat orange give me eat orange give me you." -Nim Chimpsky
ASF made a couple of mistakes in marketing:
o Apache2's biggest competitor is Apache1
o Making it run better on Windows does not win any market share for Apache2, since the installed base is Apache1
o Apache1 is being used on production servers, where people's jobs are on the line. No one really wants to be first unless there is a issue to be solved.
o MPM was mistakenly focussed upon as the selling feature. Just because MPM took the most effort doesn't mean it is the most compelling feature!
o Apache2 made the golden mistake of breaking the platform. Apache is a platform, because a lot of other software is built on top of it. The inability of Apache2 in its early development stages to be backwardly compatible with the Apache1 modules mean there wasn't much chance for people to test how Apache2 would behave in their original configuration. Currently, in many people's mind, Apache2 is being 'beta-tested' with PHP in the sense there are no real world data of PHP performance against Apache2.
o Apache2 may have broken compatibility with management tools that ISP uses as well. This again lowers the value of a platform.
Steps to take:
o PHP's biggest customers are ISPs. If Apache2 were adopted by ISPs then, all problems are solved. Partner with a large ISP, so that there are some sites running on Apache2 + PHP + other modules in their system. Offer to run profile information and offer round the clock support if the system goes down (see the problem with free software?) and publish good documentation + case studies based on this, so that other ISP's could migrate their systems over.
o Let's face it. Any code rewrite is going to break something - wrt to third party software. Somewhere. Apache2 being totally silent on this is being not credible. It simply points to the lack of adoption, and hence no one knows what is broken.
o I can't believe a ground up rewrite is not capable of offering any improvement. Apache2 has to study the key weaknesses in Apache1 either in resource consumption, scalability or performance to demonstrate what benefits can be achieved. Some real world benchmarks would be useful here.
o Failing all the technical marketing, Apache2 could focus on some hype. Get ISPs to differentiate themselves with "Runs on Apache 2" campaign, pointing out other ISPs are still running on "Apache 1".
I've been runing Apache 2.x with PHP for months. It works nicely, so I really don't care about some problems which might turn up when some dorks try to run non-threadsafe crap. I just hit them users. ;)=
--
"The more prohibitions there are, The poorer the people will be" -- Lao Tse
Tomcat (also an Apache Foundation project) is even worse. It seems that 3.3, 4.1, 5.0 and 5.5 branches are all still active.
http://issues.apache.org/bugzilla/show_bug.cgi?id= 27550
http://merjis.com/developers/mod_caml/apache_2.0
Rich.
libguestfs - tools for accessing and modifying virtual machine disk images
All of this discussion is based on a flawed idea of mod_php. Why oh why you want to have an scripting virtual machine embedded into the software which handles web requests is beyond me. People constantly complain that PHP can't run as a different user then apache. People constantly complain that PHP doesn't pool db connections.
There is a simple solution for you : Fix your bloody setup
Fastcgi has been out since 99. It spawns as many PHP processes as you want to pool. It gives each php process its own process so no multithreading problems can possibly occure. You can use apache1, apache2, boa, lighttp as your web server, they all work.
There is NO downside to using fastcgi. In my tests it even offers a 40% (!!) performance gain when you use pconnect ( which you can use now since your php processes are now pooled ) and your server now supports every scripting language on the planet becuase every scripting language worth a damn can use fastcgi.
installed mod_php is a clear sign of a flawed setup.
When accessing subversion using web-dav, you must run Apache 2 as documented here [big page]
Using web-dav and subversion is a must if you need firewall transparency. Although I found that the http sniffers on my corporate network actually slowed down my repo so I use svnserve instead (no apache / web-dav needed)
I'm using Apache-2.0.51 and PHP-4.3.10, with several typical PHP apps (webmail, photo gallery, whatever).
No problem whatsoever. I have no idea what all the fuss is about.
I entirely agree. I really, really wish more resources would be dedicated to this, because it was one of Apache 2's shining hopes when it first was released. At least to me. 8)
This is particularly important to PHP and webhosts/mass-virtual-hosters. The current model is to use things like safe_mode and openbasedir and limiting certian functions like exec(). Thats a very hacky way of trying to solve the problem of multiple users applications running as the same user without being able to mess with each other. Just saying out loud makes you realize how much a fix is needed.
Its also why any host worth its fees has to run php as a cgi rather than a module.
One module makes the switch to Apache 2 worth it from Apache 1: mod_deflate. While there is mod_gzip available with Apache 1, it does not integrate or perform nearly as well with Apache as mod_deflate.
For example, you can not serve SSL content with mod_gzip (well, you can with some tricky usage of virtual hosts at a large performance hit).
mod_deflate plays nicely with PHP, Tomcat (mod_jk) and every other module I've tried, and it results in a huge bandwidth savings for most sites and also reduces page download times.
For those who aren't familiar with mod_deflate or mod_gzip, mod_deflate compresses content before sending it to the client, and most HTML content is *very* compressible. It's not uncommon to see compression ratios of 10:1 or better.
BTW, the problems PHP has with Apache 2 is the MTM model. If you won't use multithreading, you're OK. If you use MT, make sure the underlying libraries you compile in or use with PHP are MT-safe.
I don't see why not. I use Apache2 exclusively with PHP and have never had any problems with PHP or Apache.
"There is a way that seems right to a man, but its end is the way of death." Proverbs 16:25 (NKJV)
if PHP 1.0 runs well with Apache 2.0, why bother changing PHP version?
For what its worth, here is my 2 cents.
./configure --with-apxs2=/usr/sbin/apxs --with-config-file-path=/usr/local/lib --disable-debug --with-mysql=/usr --enable-ftp --disable-cgi
./configure --enable-modules=all --enable-ssl --enable-so
I upgraded our production site to php5.0 with Apache 2 a while back. (shameless plug - t-shirtking.com)
We recently had an AP wire article released about a t-shirt of ours. It went on the front page of cnn.com and msnbc.com.
It handled 47,709 unique sessions that day (1,987.88 hourly) on a p4 hyperthreaded server with 2gb of memory. Although it created a slashdot effect, the server stayed alive during the event and many people were suprisingly patient enough to order. (we threw the drive in a dual xeon machine in early afternoon, that helped a bit) I was extremely pleased with how it performed. The server never crashed. (note, the db is on its own machine..MySQL4)
Granted, we don't use pretty much most of the plugins.
Here is my compile settings.
Now, what I was suprised with is what I learned that day about apache config. This is what I used.
Notice that this doesn't disable all the apache mods that you never use. So I could have actually had a leaner apache running on top of everything else.
My opinion, Apache2 and php5 works really well together for us. It allows us to run a site on 2 machines giving us a very low cost. Not to mention I can add a 2nd apache server very quickly with round robin dns to help spread the load in a generic way.
Anyway, hope that is useful to someone.
Josh
Actually www.php.net is and their Netcraft result shows they're using Apache1.
The PHP doc says:
"Do not use Apache 2.0.x and PHP in a production environment neither on Unix nor on Windows."
And all the PHP arguments explain that there is no compelling reason to switch from 1.3.x to 2.0.
But what's wrong with installing Apache 2.0 + PHP for a brand new install? It looks like there nothing wrong with it.
==>The PHP doc should be fair and at least recognize this.
It'll just take a while. But CVS is dying, and Subversion, its logical successor, does not run with Apache 1.3. And in our increasingly firewalled internet, subversion's apache-based access means that if you can surf the web, you can checkout subversion repositories, commit changes, etc.
It's much more convenient than cvs, especially for anonymous access (typical of open source projects).
Apache 2 has suffered from the critical mass catch-22: "I won't use it until it's better tested, deployed in more production environments, etc". Because there hasn't been a compelling reason for most people to use Apache 2, they haven't switched, prefering to stand by the age old "if it ain't broke don't fix it" wisdom.
Subversion offers that compelling reason. Many opensource hosting sites (such as sourceforge) sustain a huge number of hits per day. As subversion displaces CVS, these sites will begin to support it, and I would not be surprised if they begin running Apache 2 as their standard web server to kill two birds with one stone.
I switched to Apache 2 for subversion support. I can't be alone.
As for PHP, well, I hate to say this, but PHP's authors can't be bothered to make their module threadsafe. I know, I know, they link to libraries that might not be thread safe, but as any developer knows, there are many ways to work around possible race conditions (using locks and such) and make the system stable. That's how other programming languages (like perl and python) do it.
PHP is suffering from bitrot, plain and simple. The world around it is changing and it needs to change too. Its developers know this will be a ton of work, and so they resist it. And PHP suffers from the talent problem -- PHP is too easy to use. Bear with me for a moment -- this means that many PHP users are not technically competent enough to hack up a thread safe version of PHP, or aid in its development (this is far less true of the Perl, Python and Ruby communities).
Personally, I use mod_perl. Very nice. PHP has some good points, but some dedicated people are going to have to pull it into the 21st century or it will get left behind. Not being thread-safe is simply not acceptable these days.
The root of the problem is that the PHP Group has made no effort to document what extensions are thread-safe and which are not. Read the comments anywhere about this and they are all hypothetical. There is no list of thread-safe and non-thread-safe extensions. If there was such a list people could make an informed decision about what to use. Given how long Apache2 has been out, it is pretty clear that the PHP Group does not want people to know this information.
they want to make sure everyone is nice and compliant about upgrading when they decide to take httpd over to java like all the other java kool-aid they are selling --- Maven is Jonestown, lets all program in XML because its standard! Cultures breakdown when there is too little disent and questioning of authority, the apache foundtion is headed in that direction.
Lets move on, SOA and all that, most people don't need any of this mod_* crap and could use:
thttpd he has other servers there, too and http_load.
lighttpd I'm moving to this sweet little server for most apps and the home site runs ea php and ruby on rails
AOLServer like OpenACS runs on
Boa
fnord from our boy who did the (in)famous benchmarks
Cherokee I root for this one for some reason.
gatling
cthulhu
yaws in erlang, should support more simul. connections than the unlying OS can support.
dhttpd
Litespeed check out their php benchmarks
thy
roxen
mini-httpd never tried this one
xitami I have a intranet server running for 5 yrs (without upgrading xitami) on xitami Solaris, simple, small, easy to admin, never dies max uptime was 1000 days+.
eddiefor complex load bal and geographic distribution
hiawatha
And for the love of god, please at least design your sites to get their images from images.mysite.com if possible so that you can use a non-bloatware web server to server the images, reserving horsepower on your apache server for stuff that actually _requires_ some features of apache.
http://www.hcsw.org/awhttpd/ updated on 12-06-2004
http://www.norz.org/zawhttpd.html
http://cr.yp.to/publicfile.html
As one example, I have some dynamically generated content on the server that references a hard coded URL which has since moved. I don't have source code or even machine level access to the content generation mechanism. On Apache 1 it would have taken a fairly large effort to fix the bad URL. On Apache 2, just stick a little substitution script in the filter chain, and it's done.
looking at this, the apache guys are pissed because someone isnt going on a spazzfest on how awesome their software is.. but look at the words, php isnt saying not to use php at all with 2.0, but not to use it in a production environment. (ie, dont run it on your website that serves millions of customers a day)
Apache's reacting as if php is saying not to use apache whatsoever. Shows the immaturity of the developers. "ZOMG! YOU ARENT GOING TO SHOW COMPLETELY LOYALTY TO US! WE'RE GONNA BITCH AND CRY AND TRY TO TARNISH YOUR NAME."
It's all insecurity among the devs.
It's not like they're not going to ever support it fully for apache 2.. the current setup just doesn't yet.
Obvious solution. Quit maintaining Apache 1.3.x. If 1.3.x tree is no longer trustable and not upkept from possilbe security vulnerabilities, then it can simply die off and everybody will be forced to upgrade. Life cycle managment. Learn it. As soon as 1.3.x is no longer supported, it doesn't matter what the problems may or may not be with 2.x.x as people will switch over anyway. Fricking retards. Thats right, flame the messenger.
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.
There is one very good reason to move to Apache 2 under php: If you use multiviews, with the standard httpd config file Addtype addition for php of:
.php php3 php4 phtml
/file.php/some/thing/here/ being parsable as /file/some/thing/here/ - and for that I THINK you need multiviews (please let me know if there is a better way...)
AddType application/x-httpd-php
then sites will throw 406 errors. Some bits of google (the keitai proxy, for a start) don't like this AT ALL!
There is a workaround for Apache 2, but not (AFAIK) for Apache 1.3 (see here for more info: http://tranchant.plus.com/notes/multiviews
My sites rely on
Find Japanese addresses in English on Google Maps Japan: http://diddlefinger.com/
Oh, no. You cannot have tried this in practice. Apache still suffers heavily under load. Heavy load makes response time skyrocket. Benchmark against Gatling -- now there's a fast web server!
No. I have found that it performs the same. Kinda makes sense since its just openssl doing the actual work.
How about if you want reasonable performance, use a webserver that doesn't blow? Worker MPM is a pathetic like 4% faster than apache1 for me here. If I need performance I use lighttpd, or put squid in front of apache.