> I am building a version that handles things differently (one thread per
> CPU that does all the work), but the current design was easy to implement
> as a proof of concept.
this is what phhttpd does, it just does it in userspace. the rt queue
sigio stuff gets events from tcp to userspace, and sendfile/sigio get the
data back out. getting the data out with an async sendfile mechanism
would be cleaner again.
> myself either. phhttpd "cheats" though, it caches all files into memory
> and doesn't do a lot of things a httpd should, such as sending "Date:",
> "Last-Modified:", "Content-Type:" headers. Some of them might be easy to
> build into phhttpd, but the "Date:" header is more complex as it requires
> the daemon to send the _current_ that at the time of sending.
I added all those headers in a few hours, that stuff is trivial. Don't
confuse the cheesy http server part of phhttpd from the cool event model.
Its the latter that will go into apache; phhttpd, the web server, is just
a proof of concept. It'd pointless to turn it into a 'real' server. the
effort involved in doing so would be tremendous compared to leveraging the
sigio/siginfo model into the new-httpd work.
> kHTTPd doesn't cheat, sends those headers AND supports"If-Modified-Since"
> requests. If someone benchmarks kHTTPd agains phhttpd, this should be
> recognized.
so how does one benchmark code maintenance and portability and such?
> I don't think this is true though:
> 1) There already is a cache in the kernel, the buffercache. Caching things
> twice is insane
yes, and sendfile() gets you at it from userland. and mlock() lets you
tie down static pages you _really_ care about, etc, etc.
> 2) Caching the header is a joke since building one costs only one sprintf
> (At least, from within the kernel) and some good bookkeeping.
doesn't even require sprintf() :) (which happens to be very costly in
glibc land) lazy updating, caching, writev(), are your friends.
> Why are knfsd and the VFS in the kernel: because it is silly not to do
> this. I see no difference between a remote client that asks over NFS if a
> specific file has changed and a remote client that asks over http if
> a specific file has changed. The same for reading the content of this
> file.
no. there are many more caching/locking implications in nfs than http.
> I find the argument that kHTTPd bloats the kernel and phhttpd doesn't
> somewhat strange. kHTTPd requires no kernel patches (it helps if you
> export some extra symbols though) and no modifications to the
you're now requiring on those previously internal symbols not changing for
your code to work.
> userspace-client of your choise. phhttpd _does_ require kernelpatches and
it only fixes/extends the kernel's sigio/siginfo functionality, these
patches are needed anyway; they'll probably go in 2.3/2.4.
> those _USERSPACE_ daemons have to be tuned to Linux only. For Apache, this
> might work. But there are a lot of other (great) webservers, good at a
> specific job. They benifit from kHTTPd without any burden on their
the benefit from kHTTPd will be boiled down to an interface for caching
files and sending them out a socket, I'll wager. I'm all for that! What
I don't like is the connection management and protocol parsing in the
kernel; phhttpd (currently) and the apache 2.0 rewrite will do that for us
in userspace.
-- 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/