Linux-kernel mailing list archive 1999-23,: Re: Preparations for ZD's upcoming Apache/Linux benchmark

# Re: Preparations for ZD's upcoming Apache/Linux benchmark

Alex Belits (abelits@phobos.illtel.denver.co.us)
Tue, 8 Jun 1999 14:41:43 -0700 (PDT)

- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Next message: Raj, Ashok: "kernel_thread..."
- Previous message: Stefan Monnier: "Re: cachefs module for linux?"

On Tue, 8 Jun 1999, Linus Torvalds wrote:

> For example, to me it looks like it would be trivial to punt it down to
> user space by having the kernel module do only "peek" operations on the
> data list, and if it encounters a request it can't handle, it just pushes
> the socket onto a accept-queue - so the user space side would just accept
> the socket as if it came to it directly. So you could even use a pretty
> much unmodified apache (or other) web server to do all the non-static
> cases - although it would probably imply that the user-level deamon would
> be better off being optimized for the "uncommon" case because it never
> sees the common case.

This is what I meant in my previous message, however there is additional
quiestion about keep-alive / persistent connections. It can be possible
that client connects to the server, asks for static file, then over the
same connection asks for something else. Or it may first ask for something
else, then send large number of requests for static files. If one doesn't
want to lose connections in first case, or use userspace server in the
second one, things can become more complex.

In the first case socket should be accept()'ed by the server after the
response was returned, and in the second one server may want to "give the
socket back to the kernel" aftersending the response to request.

There is another problem -- HTTP 1.1 (as opposed to HTTP 1.0 with
extensions) allows client to make multiple requests without waiting for
responses, then server should return all reaponses in sequence. I have no
idea, if anyone really supports that (can anyone show me an example that
does?), but it can cause large amount of headache -- there is no
high-level flow control in this protocol, and unpredicatble amount of data
that arrived with requests should be buffered somewhere until all previous
requests, passed over the same connection, are answered. Even userspace
implementation can suffer from DoS attacks unless it "intelligently" drops
requests with large amount of data attached, and kernel may have hard time
making a decision, where to put POST or PUT with few hundreds of kilobytes
of data while it sends back hundreds of small files over the
same high-latency connection back.

    --
    Alex

    ----------------------------------------------------------------------
     Excellent.. now give users the option to cut your hair you hippie!
                                                      -- Anonymous Coward

    -
    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/

- Next message: Raj, Ashok: "kernel_thread..."
- Previous message: Stefan Monnier: "Re: cachefs module for linux?"