Messages in this thread | | | Date | Fri, 16 Apr 1999 19:28:35 -0700 (PDT) | From | Dean Gaudet <> | Subject | Re: 2.2.5 optimizations for web benchmarks? |
| |
On Sat, 17 Apr 1999, Stephen C. Tweedie wrote:
> 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/
| |