> OK. Most of the important points have been covered already. Especially
> the tuning of the apache server itself is one of the most significant
> issues.
Uh I dunno. Unless by tuning you mean "replace apache with something
that's actually fast" ;)
Really, with the current multiprocess apache I've never really been able
to see more than a handful of percentage improvement from all the tweaks.
It really is a case of needing a different server architecture to reach
the loads folks want to see in benchmarks.
That said, people might be interested to know that we're not dolts over at
Apache. We have recognized the need for this... we're just slow. I did a
pthread port last year, and threw it away because we had portability
concerns. I switched to Netscape's NSPR library to solve the portability
concern[1]. That was last spring... then summer happenned and I found
other things to do. In the interim IBM joined the apache team, and showed
us how the NPL sucks (patent clause), and that using NSPR would be a bad
thing.
Months went on in this stalemate... we finished 1.3.0, .1, ... We kept
hoping netscape's lawyers would see the light and fix the NPL. That
didn't look hopeful -- so IBM started up a small team to redo the threaded
port, using everything I'd learned (without looking at my code... 'cause
it was NPL tainted), and port to pthreads. Their goal: beat their own
webserver (Go). This port is called apache-apr, and as of today someone
posted saying they'd served 2.6 million hits from apache-apr over a 4 day
period. Not a record or anything, but an indication of stability.
Oh, netscape fixed the patent clause. Or they're supposed to be releasing
the fix. But we're down the road far enough now we won't turn back.
At this point apache-apr isn't in a state where we want zillions of people
using it, because it's probably still full of bugs. But if you really
want it, visit http://dev.apache.org/ and dig around in our cvs stuff...
just don't expect hand holding.
Oh, to forestall anyone saying "apache should be a poll/event-loop style
server to go the fastest"... yes, you're bright (but probably wrong[2],
and if I digress any further I'll make myself puke). Apache will never be
the fastest webserver, because that isn't our goal. Our goal is
correctness, and useability. Performance at this level is mostly a
marketing gimick.
Dean
[1] NSPR had a feature that had me excited -- hybrid userland/kernel
threads. I suspect these won't be necessary to do well on benchmark
loads. But on real-life loads where there are lots of long haul clients,
these might be real nice... you won't need to chew up a kernel resource
for each client. Something for linuxthreads folks to think about.
[2] insert discussion about kernel assisted http serving here, reference
IBM's and Sun's published 4-way xeon specweb numbers with kernel
accelerators.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/