> I believe what khttpd will be great at is a benchmark target. If a
> userspace httpd can beat khttpd's numbers, then we know we're on the
yes, userspace httpd servers can beat in kernel ones. Both historically
(have the hordes advocating khttpd talked to the Zeus folks, for example?
I have, 3 points to whoever guesses what I learned.) and in the current
linux landscape. I will be releasing numbers and profile runs and perhaps
a paper in the near term.
In the long term, I want to see this async/sigio model worked into the
apache 2.0 static engine doohickey dean is hacking on. That will be nice
and portable, won't require folks changing software, etc, etc.
> right track. Stephen Tweedie was telling me at Usenix about some of the
> good work which Zach Brown has been working on. Basically, it uses the
> POSIX real-time signals plus O_ASYNC to completely eliminate the
> thundering herd problem as well as the need to use poll() or select()
> and the overhead engendered by those functions. I think it's a very
Yeah, thats a good quick summary :) It does some other neat tricks with
headers and such, but thats applicable to any sort of event loop static
server. One of the more clever things its able to do is pass listen sigio
events around with SETOWN.. insta-load-balancing amongst the threads that
are spinning on their own event queues.
> promising approach, that may very well be just as fast as khttpd while
> still giving all of the flexibility that user-space httpd can offer.
*nod* That bit deserves a bit of underlining, as its my whole 'complaint'
with the khttpd effort. I have no objections what-so-ever to Arjan
experimenting with this stuff; I wish him the best of luck. But we can't
generally aim the OS in that direction. We should put some facilities in
place that will allow all userland, including httpds, to go fast as hell.
what happens when we look up and openldap is slow as reported by MS
benchmarks? INN? sendmail/qmail/postfix?
the solution is to update the userland daemons to use 'modern' apis and
methodologies and such, not to punt and put the protocol in the kernel.
The former is what apache 2.0 will do, I hope.
The most kernel hacking that I feel makes sense is adding an async
sendfile() completion event of some kind..
> The name of the game here is to be able to smoke Microsoft on its
> benchmark numbers while *still* offering as much flexibility as Apache
> can offer. The benchmark numbers are to counter Microsoft's FUD. The
> power and flexibility is what will make everyone switch. :-)
or continue using it :)
-- zach
- - - - - -
007 373 5963
-
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/