Slashdot Mirror
Apache 1.3.x vs. 2.0.x: The Debate Returns
darthcamaro writes "internetnews.com is running a story about the new Apache 2.0.49 release. They actually got a hold of a pair of Apache Software Foundation members and got them to speak out about the 1.3.x vs. 2.0.49 debate! Also Apache Director Sander Striker told internetnews.com that he expects the Apache 1.3.30 release cycle to begin this week... I still use 1.3.x because I've been using the Apache 1.x series 'forever' and I've never found a solid reason to change. Also, as pointed out in this article, the official PHP documentation clearly states, 'Do not use Apache 2.0 and PHP in a production environment neither on Unix nor on Windows.'"
The PHP manual link posted is a direct link to one of the Canada mirror servers. The PHP site is mirrored around the world and it automatically selects your nearest mirror server.
:D
Use http://www.php.net/manual/en/install.apache2.php instead so that it can select the nearest mirror server and save us slashdotting this one Canadian server
(\(\
(^.^)
(")")
*This is the cute bunny virus, please copy this into your sig so it can spread
From what I understand, It's all about the performance. Apache 1.3.x supposedly has better performance with PHP when compared to the corresponding Apache 2.0.x release.
My blog
It's almost two years old.
Taken with a grain of salt of course, but I heard that the issue was about 2.0's use of threading whereas 1.3 was always a prefork model. mod_php made certain assumptions in their implementation for the Apache 1.3 version that didn't turn out to be threadsafe -- an obvious problem for Apache 2.0. But then I would tend to say it was a PHP problem rather than an Apache2 problem.
It doesn't surprise me that 1.3 would be the performance winner at first. 2.0 was concentrating efforts on the worker (multi-process/multi-thread) model. Then again, it's been two years since that performance reference was written. Is the performance gap still that wide?
- I don't need to go outside, my CRT tan'll do me just fine.
I've been using both 1.3.x and 2.x with Tomcat and I have yet to really notice a difference except that the config files for 2.x seem to be laid out in a more sane order though it took a while to adjust. (I can't speak to PHP usage as the only time I touch it is for running squirrelmail)
As another user pointed out, you don't need to have Apache 2 running as your webserver if you want to access Subversion. You can do one of the following:
-
Run Apache 1.x as your webserver on port 80, and then have Apache 2.x
running side-by-side as a separate server and have it listen on port
3690, the port that
IANA
has reserved for the Subversion protocol.
-
Instead of Apache, run the lightweight Subversion server
svnserve. It's quite simple to set up compared to Apache,
but can only grant blanket read/write permissions. Also, you can't
fine-tune
permissions on a per-directory basis like you can with Apache.
-
If you have pre-existing accounts on your system, you can tunnel
through ssh via the svn+ssh://host/path/to/repo pragma which will
authenticate itself via ssh and use the Unix file permissions on the
repository.
-
If you are the only one accessing your repository, you can even use
the
file:///path/to/repo pragma and forego a server altogether.
Each method has its benefits and disadvantages, you will want to evaluate all of them and choose one best suited to your business logic. Also, you definitely want to read over the upcoming O'Reily book Version Control with Subversion (see Chapter 6, "Server Configuration"). Good luck.Thomas
It would be interesting to know if PHP 5 will be thread safe, and this usable in production with Apache 2.x
PHP will probably NEVER be thread safe.
Even if PHP were 100% threadsafe, it generally uses too many libraries for it to be practical to make sure they're ALL threadsafe.
Even if PHP were 100% threadsafe, it generally uses too many libraries for it to be practical to make sure they're ALL threadsafe.
Actually the PHP core is 100 percent threadsafe now, it is only specifically the external libraries which aren't.
If you use PHP w/FastCGI support you wont run into these issues. If you only compile MySQL or Postgres support into your PHP you wouldn't either. But many users frequently also compile in other external libs for things like graphics generation, url manipulation, etc and its these libraries which aren't thread safe and specifically can cause problems in high use environments.
While you could specifically use PHP and Apache2 in total prefork mode, this basically makes it run exactly like the 1.3 series, so then the real question is what's the point of upgrading at all and not just sticking w/1.3?
I'm using RackSpace and the only way I can get PHP 4.3 and Postgresql 7.4 is if I use RedHat ES 3.0. It uses Apache 2. The only other option is to use PHP 4.1 and Postgresql 7.1. Stupid RackSpace. I would have used FreeBSD except they don't support it as they do with RedCrap.
The above is not worth reading.
I've been running it on WinXP without any problems either.
-- There is no spoon. Only fork.
Because some servers like the subversion apache module require apache2, and I'd like to not have to run both apache1.3 and 2 in parallel. I am curious as to why the php documentation doesn't mention that using the prefork mpm and php would work fine however.
Since PHP 4's inclusion of the Zend Thread-Safe engine, PHP itself has been thread-safe. It is the third-party libraries that extensions link to that are non necessarily thread-safe.
_ safety.html#liblist
There's a list of libraries and whether or not they are known to be thread-safe here: http://httpd.apache.org/docs-2.0/developer/thread
Gabriel Ricard
Check out the guide. I've been running it like this for over a year.
It can be done, but it is a little touchy. Check the Wiki.
Once I've gotten it running, though, it has worked correctly, so the hard part seems to be just getting it running. I'm actually using it in a 'production' environment, too, perhaps a little bravely, but it's better then the alternatives.
One of the posters found this more recent comment from Rasmus as well:
rm -rf / is the evil of all root
mod_python has been on Apache 2.0 for almost 2 years now.... :-)
Just to be the voice of dissention ... I'm apparently the one person in the world for whom the PHP+Apache2 combo doesn't actually work right. Yes, it mostly works, but I'm constantly having to close out the windows that pop up when a thread goes boom. Yes, I am running it on XP (with all of the necessary service packs and hotfixes), but that shouldn't invalidate the fact that PHP+Apache2 isn't production-quality stable. And yes, I am 100% sure it is PHP causing the problem, as the errors only started when I started using PHP, and they increase as I convert more and more of my site to PHP.
Now, if I'm getting all these errors, why am I using it? Because it's still better than the alternative. When any DLL goes pop under IIS you get really flaky and esoteric things that start happening. Under Apache2 it just nukes a thread, which Apache2 diligently respawns and goes on with life. I can deal with clicking OK on a dozen windows a day if it means I don't ever have to worry about restarting my web service.
PHP+Apache2 isn't perfect, but it's good enough for what I need.
Just was tinkering with mod_frontpage and it's now basically Apache2 only. They still have support for 1.3x, but it's being phased out from what I can tell.
:p It runs as well as anything MS related can under linux... ;)
And installing it under 2.0.49 wasn't too bad after I realized that it REQUIRES the 'bin' user.
don't run apache2 in parallel on that port - that port is reserved for the svnserve _protocol_, and clients will get all sorts of confused if you try to connect with a svn:// url to it.
You can also run apache2 listening only on localhost, and set apache2 up to proxy to the apache2 instance (if you don't trust exposing apache2 at all)
For Redhat 9 and probably other distributions, Apache 2 and PHP are supported out of the box.
I have been using it for a year or so too but the same Perl, DBD::Pg and HTML::Mason code that ran for hundreds of days of uptime in 1.3 now have major memory leaks that freeze the machine unless I reboot daily. Luckily I have 9-5 East Coast users so I can get away with it.