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.
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..
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'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
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.
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.
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
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
The /. moderators really don't have any control over what appears on /. or not...you should be ticked off at the Editors!
Doh!
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.
mod_perl 2.0 hasn't been released. RC1 of MP2 has been released. I'm pretty sure you'll be able to count on MP2's formal release making slashdot's main page.
Stick with kernel 1.3.79 and Apache 1.1 just to be "safe".
Are you intolerant of intolerant people?
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.
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.
Ahh and while I agree there was a very small announcement on search.cpan.org.
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
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/
. . . 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
>Apache 2 has a non-free license
I must not understand the lingo, how is it not free?
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
Comment removed based on user account deletion
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.
ever try out a basic hello world type application in PHP and have it inexplicably start showing you values from other peoples' sessions? Values like names, addresses, credit card numbers? I've never had that happen in PHP, but when I tried mod_perl (and yes, I know perl), I started seeing that happen. No, I dont know why. I know this happens to other people, too. I dont _care_ why. Anything which can let you do that without knowing why- by fucking default -should be avoided.
And Java is crap.
(this is _NOT_ a troll post. This is an answer to a question.)
-- 'The' Lord and Master Bitman On High, Master Of All
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.
then the user would have to force the install if the PEAR modules they plan to use are ok.
Binaries... compiled safe only.
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.
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?
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
The points brought up in the site you link are valid. It's one thing is someone were merely spatting out nonsense, but when they have valid points they can demonstrate, it's good to make note of it.
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.
Perl is fine, with one exception: the "there's more than one way to do it" concept. Anyone suggesting to use such a language in any serious software project should be fired with prejudice.
I actually mean it.
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.
I know nothing of the Java language, I know only that I have never seen Java used and thought to myself "this is not an abysmal peice of crap, and it runs smoothly enough that it is useable"
-- 'The' Lord and Master Bitman On High, Master Of All
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)
Ok, let's assume your stance: there should only be one way to do something. Fine: anything that can be done, only one way to do it.
In that case, there are only two positions you can be in:
1) Anything you could possibly do has already been done once, so there's no use for you. You're out of a job.
2) There are still some things left, but once you do them (or anyone else does), that's it, there's no use for you. You're out of a job.
Don't be so obtuse. Programming languages are tools, not soapboxes.
--
Promoting critical thinking since 1994.
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.
Right, the either-black-or-white view, the hallmark of those who deem themselves intelligent but are merely able to accomplish some marginal and narrow task.
It's bad when there's strictly one way to do it.
It's a very good thing when there are just a few ways to "do it", chosen for valid reasons.
It's a pathological case when the language chooses as primary goal to bundle heaps of different ways to "do it" just for the heck of it. Perl is like that.
As for the two positions you mention: you mean there are jobs in the field of programming just because there are more ways to implement the same algorithm over and over? Don't be ridiculous!
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.
Don't be silly. The guy actualy comes up with some good arguments. I use both Perl & PHP and I happen to agree with them. I'll keep using PHP, tho...
As for the 'more than one way' argument, I've never met a programming language yet in which there wasn't more than one way to do things. There's more than one way to do things in PHP (thankfully).
I think you guys are confusing programming with bookkeeping. You're wrong. Programming is an art and in art there's always another way...
X.
I guess the excludes C (and probably most other languages). You sure wouldn't want to write
/* Never used i++; !!! */ /* No = operator needed */
int i;
for ( i=1; i=5; i++ ) {
printf( "Hello, %d\n", i );
}
when you could write
int i;
i = 1;
helloloop:
printf( "Hello, %d\n", i );
i = i + 1;
if ( i 6 ) goto helloloop;
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.
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/