lkml.org 
[lkml]   [1999]   [Jun]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    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 majordomo@vger.rutgers.edu
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2005-03-22 13:52    [W:0.025 / U:30.168 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site