> > what we _do_ want is a nice API for doing async bulk file->file
> > transfers. Thats all the meat of khttpd really is. We can get this
> > with a bit of thinking and proper async io. This will happen in
> > time.
>
> Even without async bulk file->file support, how close do khttpd
> performance do you think you can get with phhttpd?
The people working on the Roxen (www.roxen.com) webserver conducted some
tests.
Roxen is a single-process webserver, and the tests were conduced using
some (experimental, but publicly available) features that will go in the
next release, using an highly optimized backend.
The tests were your tipical "get-high-numbers-to-impress-marketing-people"
setup, namely a set of clients hammering a server for static files in
optimal conditions. It is to be noted that the server ran under Solaris
2.7 x86, but some results can be of interest in this context.
It turns out that the single most CPU-consuming activity was parsing the
HTTP request headers. Doing that in kernel- or in user-space won't change
much, as the headers are usually small but not structured for automated
parsing. The parsing operation will always be dominant when compared with
other operations: we already have the mean to do efficient bulk file
transfers, and that's sendfile() (it can be noted that Roxen uses
sendfile() also for dynamic content, I don't know about Apache or other
servers).
What I'm trying to say is, we're looking in the wrong place here. True, an
HTTP server in the kernel might sound good to get more performance, but
the focus should rather be moved to designing better (userland) software.
This said, if somebody wants to write a kernel HTTPD, I won't try to stop
him, why should I? I'll just avoid using it :-)
-- Kinkie primary e-mail: kinkie@kame.usr.dsi.unimi.it[random fortune] Never play pool with anyone named "Fats".
- 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/