Is Apache 2.0 Worth the Switch for PHP? 465
An anonymous reader writes "It seems like some of the members of the Apache Software Foundation are a little angry with the PHP Community because they don't recommend using Apache 2.0 with PHP. Since PHP is installed on half of all Apache servers this is a major issue for them. A number of high-profile PHP community members such as John Coggeshall and Chris Shiflett have blogged about this decision in light of a recent posting by Apache Software Foundation Member Rich Bowen which called PHP's anti-Apache2 stance FUD. Is there any real reason for the PHP community to start recommending Apache 2.0, especially when the 1.3.x series of Apache is rock solid and proven? Note Rich did later commend PHP for being a great product, so it's not all flames."
PHP used to be an ASF project (Score:5, Interesting)
I should probably be noted that PHP used to be an official Apache Software Foundation project until it was mutually agreed to end this relationship. I have no clue as to what the underlying reasons were and as an ASF member myself would rather not speculate on this. See ASF Board Meeting Minutes [apache.org] for Feb 2004 (section 5.G).
P.S. Apache 2.0 is great and there is no reason not to use it IMO.
It's a threading issue (Score:5, Interesting)
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
No need to switch ... (Score:5, Interesting)
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".
A solution looking for a problem. (Score:1, Interesting)
If Apache wanted people to move to 2, they should provide benefits that make people want to go through the effort to move.
Nobody told me! (Score:3, Interesting)
What is supposed to be the problem?
Re:FUD in it's purest form ... (Score:3, Interesting)
Using PHP on Apache 2.0 right now. (Score:5, Interesting)
The one thing that I wish PHP would take advantage of in Apache 2.0 is the ability to run code as a user other than the web server. Every time I bring this up with the PHP developers, nobody really runs with it. A feature like this would make PHP much better in shared systems and prevent people from having to do weird things to ensure security. I guess PHP is not that great for shared systems right now.
Re:PHP used to be an ASF project (Score:2, Interesting)
What extensions? (Score:4, Interesting)
Re:Why are there two?? (Score:1, Interesting)
The apache foundation is one of the FEW open source projects that actually do this. Its probably one of the reasons why the apache webserver is so ubiquitous.
On the other end of the spectrum, you have jboss. Uggg. Go from 3.2.3 to 3.2.5 to 3.2.6 and all are MAJOR upgrades in terms of effort to migrate your code base to the new versions. Its horrible. I would have loved it if 3.2.3 had been supported with regular patches, upgrades etc... but was forced to move to the higher "point" releases. bleh.
apachetoolbox supports the 1.x apache (Score:3, Interesting)
I've done the roll-your-own apache/mod_perl/mod_php/mod_etc.etc.etc... thing before. I'd love to have those hours of my life back. So if the Apache foundation really cares about evangelizing 2.x why don't they create something as powerful as ApacheToolbox that actually works with 2.x?
Re:Homegrown apps are one thing... (Score:4, Interesting)
Bruce
I think they're right (Score:4, Interesting)
Personally, I'd like to see more server alternatives to Apache anyway. I think there should be a handful of FOSS web servers capable of hosting PHP, web servers that make different kinds of tradeoffs between performance, security, and ease-of-use. The huge market share that Apache has, from my point of view, is a problem, just like the huge market share that Microsoft has in other areas.
Re:It's a threading issue (Score:3, Interesting)
I don't understand.
Are the PHP developers not recommending Apache 2 because it is harmful to upgrade? Or are they not recommending Apache 2 simply because there really aren't any benefits to upgrading.
Upgrading (and rolling back an upgrade) Apache has always been pretty simple, and it's pretty easy to have a 1.3 Apache running alongside an Apache 2.0.
Don't see the issue with Apache 2 and PHP (Score:2, Interesting)
Apache Tweak. (Score:5, Interesting)
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!
Much the same as... (Score:3, Interesting)
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 [kernel.org] to see another example of this in action.
Re:PHP used to be an ASF project (Score:2, Interesting)
Re:No need to switch ... (Score:2, Interesting)
I know, suggesting that Slashdot might be misinterpreting my words is close to heresy
Re:FUD in it's purest form ... (Score:3, Interesting)
Bruce
Re:Apache2: The only choice for Win32 (Score:4, Interesting)
Apache 2 threaded MPMs can run different vhosts under different users, so this has been fixed for over two years. If PHP was thread-safe, you wouldn't have a problem, but as this story highlights, PHP doesn't play nice with threads.
Re:It's a threading issue (Score:3, Interesting)
As I recall, an old benchmark showed that a 486 running Linux and Apache could saturate a T1 serving static content. I'm not sure what benefit a "static content" metric has to any discussion concerning modern Web technologies. If static content is your problem, there are gobs of Web server solutions, such as that old kernel HTTP server, whatever it was called. Threading, pre-fork, blah blah blah--it's all gobbledy-gook when you're talking serving plain-jane HTML files.
I think Apache solved the problem too well with the 1.3 branch. It's a robust, fairly clean solution to serving Web content, either static pages or some degree of dynamically-created Web application. If you need to do either, or somewhere in between, Apache 1.3 is a decent solution. The way I see it, if Apache wanted to differentiate their 2.0 branch, they could have gone either one or both of these routes: 1) build it with the intention of catering to the Web application market; or 2) build it with the intention of catering to the Web hosting business.
With 1), the core problem of dynamic Web sites is the glue between a database and the HTTP server. Quite a lot of Web sites would be equally well-served by a lightweight HTTP server on top of a relational database. Something like Oracle's IAS, but... not. If Apache 2 could offer something like that, then they would have something to offer Web application developers. (And, incidentally, create a new market the way Tomcat/Java servlets did and thus a stable base of users.)
With 2), there's a lot of work done by companies such as PSoft and Ensim to provide a facility for hosting several Web sites from a single IP address, and allowing those Web sites to have some control over their site. If Apache 2 could offer some method for improving this situation--"how" I leave as an exercise for the reader--then they would have something to offer hosting companies. (And, incidentally, create a whole raft of adopters as most people who buy Web space at a hosting company for $29.95/mo, or whatever, don't give a fig for what HTTP server is running behind their site.)
As-is, Apache 1.3 can do both 1) and 2) good enough, and as we all know, good enough is good enough. Everybody will eventually move to 2.0, if only because RedHat stops supporting 1.3 in their up2date utility. I don't think there will be a mass exodus to Apache 2.0 for any technical reason, like the movement we see today towards FireFox from IE, because Apache 1.3 isn't a complete piece of shit. It's pretty good, as a matter of fact, and that Apache 2.0 isn't exactly bursting with new, revolutionary ideas that can change the world, the change will come slowly and quietly, until one day you'll sit up in bed and wonder, "Whatever happened to Apache 1.3?"
Re:FUD in it's purest form ... (Score:5, Interesting)
Re:FUD in it's purest form ... (Score:5, Interesting)
As for putting a lock around them, I'd imagine that when that happens, it would be considered thread safe *except*...
PHP has a user contributed library system similar to CPAN called PEAR. Some of the libraries in PEAR aren't threadsafe... and even if somebody went through and updated them, next week there will be several new one that are not threadsafe.
Now, all of this would be moot if there were a compelling reason to push to Apache2. The impetus would be there to do the work. But, right now, the last of the 1.x series is just as stable and performs as well as Apache2. That means that there's simply no reason to do the work, and Open Source doesn't like to do unnecessary work.
When there is a benefit to the ongoing work necessary to make it and *keep* it threadsafe, it will likely be done.
--
Evan "And yes, I realize the irony of saying how Open Source works in this reply"
Re:Why are there two?? (Score:1, Interesting)
Heck, it doesn't help that they have an "alpha" 2.1 line, that makes the 2.0 line feel even more like its in beta testing.
Re:apache2 is essential for Windows (Score:4, Interesting)
It all goes back to Windows NT being designed from the beginning to enourage the use of threads, while Unix always favored multiple processes.
Re:FUD is logical. (Score:3, Interesting)
This is what I want to know. Which modules use libraries that are threadsafe (or have threadsafe versions)? Which modules are known to crash the thread?
I build php here with postgresql as the only additional library over whatever the default modules are (and I have found threadsafe patches for libpq). Is having threadsafe libraries enough?
Re:Homegrown apps are one thing... (Score:3, Interesting)
Which, as I have remarked earlier, is a sympton of PHP never having been designed to run on Windows.
Maybe there's an opportunity for someone to get famous by writing PHP interpreters in both Java and C#, and then they can sell it to all the PHB's out there who can't decide whether to go with J2EE or
mod_lisp (Score:3, Interesting)
The bloat is BEFORE sendfile() (Score:2, Interesting)
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
PHP suExec is available. (Score:3, Interesting)
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.)
PHP-as-CGI doesn't work on many web servers (Score:2, Interesting)
I worked out this problem a while ago, submitted bug 28227 with fix [php.net], 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...
Re:PHP used to be an ASF project (Score:2, Interesting)
Apache2.0 = XFree86 (Score:3, Interesting)
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.
Re:Using PHP on Apache 2.0 right now. (Score:3, Interesting)
i agree completely- i have had no end of problems with one of my co workers who continually writes code that requires register_globals and magic_quotes_gpc, no matter how many times i ask him not too. and even though i have told him that those options will be turned off for any new system that i set up, he still asks me why his code is breaking every time i set up a new site...
what's really annoying is that this guy is the most paranoid guy i've ever met when it comes to securing servers against remote shell exploits. apparently he couldn't care less whether he is writing exploitable web sites, though...
Re:PHP used to be an ASF project (Score:4, Interesting)
For instance, i am unable to upgrade my server to php5 because many customer code won't run correctly on it.. But before too long, we will have customers demanding php5 because their code doesn't work on 4..
Re:Using PHP on Apache 2.0 right now. (Score:3, Interesting)
Imagine if every system had a gcc.ini, a glibc.ini, and so on?
Imagine if allow_pointers, disable_switch_statement, and short_circuit_boolean were system-wide global settings?
Good luck getting enough compatible software on a system to even boot it!
A language should have defined default behavior. If you want to modify the default behavior, this should be done via a directive in the source code of some sort. Then each program can have its own settings. If you have a webserver with 100 programs on it, and one requires register_globals, why enable this for every piece of source on the server?
Re:Stop picking on PHP (Score:3, Interesting)
This kind of misses the point. The assumption "why bother with apache 2.0 if it doesn't run in multi-threaded mode" misses all the cool things that have gone into apache 2.0 outside of the threading models. I'ts a lot saner, and has cool things like chaining (output of CGI can go through SSI) and a million other things. The PHP guys should just say "run it in the old MPM mpde and have fun" which is I think the real sticking point.