Apache 2.0 Goes Gold!
The Apache Software Foundation's Apache
HTTP Server, version 2.0.35, has now been released for General Availability. You can find the official announcement, and download the server, from their website. Be sure to try a mirror first. Congratulations to the HTTP Server Project for getting the final release out. If you are wondering about it being usable in a production environment, you should poke around Slashdot's servers and see if you are surprised (now if only mod_perl was finished we could move more of our servers over to using the new release).
The HTTP Server Project is now recommending this release for use on production websites. 2.0.35 is now considered their best release and should be used in preference to all older versions (including the 1.3 series). A few of the new features are:
- higher performance over 1.3
- multiple operational models: threaded, hybrid multi-processes and multi-threaded
- specific request processing for Windows, Netware, BeOS, and OS/2
- integrated SSL and WebDAV support
- improved HTTP proxy support
- I/O layering and filtering
Upgrades are a little early unless PHP starts compiling in, especially statically. (A la mod_php without DSO). They're getting close, php 4.2.0 should work I suspect, whenever it or any other previewish release comes out.
Also, be nice to get some good benchmark numbers. Speed / SSL / Dynamic Content seem to be things just about everyone relies on, and it'd be great to have a nice case to move from 1.3. I know the Apache team has made a lot of progress on this, be great to see it validated.
Bravo all around of course.
- August
I bet Apple will have Apache 2.0 available thru their Software Update or whatever for the OSX Server.
They are usually pretty good with stuff like that.
There are apache2 module binaries in the tomcat4 directory, at least for mod_jk which i prefer on principle
Looks like a Debian developer is already on top of it--see the announcement in the debian-apache mailing list.
They're not "official" yet, but here you go.
a while ago.
KDE 3.0, Apache 2.0, Mozilla 1.0, myownsillyproject 0.0
Apache 2 is great. I have been testing/playing with it for about 2 years now. I luv the thread/process model. and I luv the built SSL and DAV support. However I would have really loved it, if it had built-in LDAP auth module. When I started testing it initially, there were talks of including the module in the source tree. But they dropped the idea. I have tested several previous releases of Apache 2 and none of them had support for LDAP, nor have I figured out a way yet to compile LDAP auth module into Apache 2 as of yet. Any ideas/thoughts?
Consensus is good, but informed dictatorship is better
I can remember krow (aka Brian Aker) tell me in IRC about how he setup apache2 to just server images. Like the most simple thing you can do. It requires no special threading, or proces modes, just http1.1. At most, they can do geographic ad targeting with revers DNS lookups tied to the image servers. Blah... still not that special, but at least they can say they run apache2. I have also read where he claims apache2 is't ready for prime time. This is very telling, not because he is senior Slashdot developer, but more because he is known best for his apache 1.3 modules, such as mod_mp3, or mod_layout.
It isn't a lie if you belive it.
Not to spoil it for you or anything, but you really should have at least a *marginal* understanding of optimizing compilers before you go pretending to be an expert.
.s files here, but our old friend the lameness filter clobbered them)
I don't mean to be nasty here, but NOTHING offends me more than an arrogant ignorant person. We all make mistakes, and thats cool, but when you jump down someone elses back with condescending remarks you better be sure that you know what you're talking about.
Without further ado, here are two C programs:
add.c:
main(){ int i; i = 0;i++;}
add2.c:
main(){int i;i = 0;i+=1;}
Now, we compile them using the -S option on gcc (in my case on a SPARC running Solaris, but I'd wager you'd get similar results on just about any supported architecture). So again, we do a:
% gcc -S add.c
% gcc -S add2.c
(I tried to post the
Now, do a 'diff' on 'em. Draw your own conclusions.
Apache will never run as fast as iPlanet or Zeus because it is more sophisticated. It's definitely better than Apache 1.3 as of late, though. Look through the archives for dev@httpd.apache.org and search for a message from Brian Pane a week or two ago when we were putting the finishing touches on the bucket brigades API work... he posted some performance comparisons there.
... maybe in Apache 2.1 or 3.0 or whenever we get the async I/O MPM that we've been talking about, then we'll come closer. But still, you just have to expect that it's a tradeoff: do you want ultra-fast performance on a fairly simple web server, or do you want really good performance on highly customizable web server?
As for iPlanet and Zeus
The short answer to your question: while yes, you can probably get your 1.3 config to work without *too* many changes, you should spend a bit more time exploring Apache 2.0, or you'll miss out on a lot of the benefits.
The configuration is totally different; it uses GNU autoconf now instead of the home-grown APACI system. The two have many similarities, but you should peruse all of the
options carefully.The perchild MPM (which provides the configurable userid per Apache child process that you mention) is possibly not yet working; it's still classified as experimental. But we'll probably be getting that cleaned up within another release or two.
For installation, I found that the easiest thing to do is to add
Somewhere in the document and, for indexes,
before the DirectoryIndex (which must be modified to add index.php). The CVS version works also, but I had problems with some scripts under it. Hope this helps. SiMac450
MSVC
; 1 : main1(){ int i; i = 0;i++;}
00000 55 push ebp
00001 8b ec mov ebp, esp
00003 51 push ecx
00004 c7 45 fc 00 00
00 00 mov DWORD PTR _i$[ebp], 0
0000b 8b 45 fc mov eax, DWORD PTR _i$[ebp]
0000e 83 c0 01 add eax, 1
00011 89 45 fc mov DWORD PTR _i$[ebp], eax
00014 8b e5 mov esp, ebp
00016 5d pop ebp
00017 c3 ret 0
; 3 : main(){int i;i = 0;i+=1;}
00018 55 push ebp
00019 8b ec mov ebp, esp
0001b 51 push ecx
0001c c7 45 fc 00 00
00 00 mov DWORD PTR _i$[ebp], 0
00023 8b 45 fc mov eax, DWORD PTR _i$[ebp]
00026 83 c0 01 add eax, 1
00029 89 45 fc mov DWORD PTR _i$[ebp], eax
0002c 8b e5 mov esp, ebp
0002e 5d pop ebp
0002f c3 ret 0
Identical.
Haste is always a good thing, but if you read what Apache said, they've been running it on their site for ages (5 months), along with every script kiddie, cracker, hacker, pipe smoker, sql stinker, checking it out since the ip address of the server was alive and kicking on the net; I think it just might be a tad stable...but who knows....nothing is perfect, not even gold. Oh, wrong, gold is a pure element isn't it.
These days it is.
The bitkeeper versioning system the kernel guys (Linux & Marcelo) use does for them.
Great. And unless you need to run something on the scale of slashdot (in terms of cgi dirty work/complexity) I would much rather run thttpd. It's faster and smaller, with much less overhead and much (much) more secure. I've never needed all the bells and whistles of apache, and I doubt 80% of the people who use apache do.
--
#nohup cat
I haven't used the Kiwi File System though.
Bleh!
There might be a patch you need, because I know for a fact that several developers reported 2.0.35 testing out fine on their Solaris 8 boxes before we released it. I've forwarded your comment to dev@httpd.apache.org and will let you know if anybody comes back with an answer to this problem.
Hmmh. I may be wrong but:
Does this not indicate that this is not necessarily true any more? Plus, on some platforms limitation is pretty high, esp. for threads ('full' processes usually have lower limits).
I like paying taxes. With them I buy civilization -- Oliver Wendell Holmes
the prefork MPM is the default on Unix in general. We talked about switching the worker MPM (the hybrid threads/processes one) to be the default, but didn't do it for some reason or another. That's not to say that you shouldn't use the worker MPM... if your platform has good threading support, then by all means, worker is the way to go. It scales far, far better than prefork. However, it's true that you can't run a threaded Apache (and therefore the worker MPM) on FreeBSD right now. We're working on that, but it's still unclear exactly where the problem is.
the prefork MPM is not listed as experimental. If it is, it's a mistake (tell me where it says that and I'll change it!). The only one that's listed as experimental is perchild, which is the one that lets you configure the server to run certain virtual hosts under certain child processes and to assign different uid's to each child process.
Plenty of people want dynamically driven sites; something httpd isn't aimed for.
:)
Personally I use quite a few of the features of Apache; mod_php (thttpd has this, but each script blocks the server, Not Good[tm] unless your scripts are trivial), mod_proxy (Outside world -> FreeBSD/Apache -> WinXP/Apache, appears as part of my web tree, nice and clean), mod_rewrite (how anyone can put up with the crappy URL's dynamic sites like I don't know, a 1:1 mapping of URL's to the filesystem is bad enough) and mod_gzip (does thttpd support any content negotiation?) to name the main ones, and this is just a miniscule personal server
You only got burned by the bug if you actually saw the problem - like say me. I'm actually the one who reported the reproducable test case for this bug. The bug has been in the system since the introduced WAL in 7.1. And how did I find it? Pg crashed in our production environment and we got duplicate inserts primary keys after it started up again. At least it's fixed now - and going from 7.2.0 to 7.2.1 is _not_ a hard thing: compile, install, stop/start. Couple seconds of downtime?