Messages in this thread |  | | | Date | Sun, 20 Jun 1999 16:08:02 -0400 (EDT) | | From | Zach Brown <> | | Subject | Re: 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 majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
|  |