[lkml]   [1999]   [Jun]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: kHTTPd: Good or Bad

On Sat, 19 Jun 1999, Arjan van de Ven wrote:

> 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
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:52    [W:0.056 / U:6.236 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site