lkml.org 
[lkml]   [1999]   [Nov]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Max tcp connections

> From: Alan Cox <alan@lxorguk.ukuu.org.uk>
> Date: Wed, 17 Nov 1999 21:40:36 +0000 (GMT)
> To: jg@pa.dec.com (Jim Gettys)
> Cc: alan@lxorguk.ukuu.org.uk, davids@webmaster.com, sct@redhat.com,
> linux-kernel@vger.rutgers.edu
> Subject: Re: Max tcp connections
> -----
> > Alan, you are being too flip. I'll give you an example of an existing
>
> Given the amount of argument to no avail
>
> > This principle is why X works well under load (actually, will work alot
> > better interactively in XFree86 4.0 due to recent X dispatcher changes
> > Keith Packard has made): in fact, in X, you get WAY under one system call
> > per operation (or even client with requests to process), do to a combination
> > of batching requests, and this behavior of select.
>
> X is very different. X is a single unthreaded CPU intensive blob typically.
> The situation where apps overrun X is very normal

And should be for web clients as well: a single html page typically has
a bunch of embedded links.

>
> > It means that under load, the X server gets more and more efficient, a
> > property that is highly desirable for network servers in general.
>
> Indeed, but just not how the cookie crumbles on a web server. X is so
> different. X is the other end of the spectrum
>
> Web: large numbers of slow connections doing fast to complete operations
> X: smaller number of high speed connections doing slow to complete
> operations.
>

Huh? X requests may take less than 1 microsecond total to execute, including
both client and server on current hardware. Even this slow celeron I
write at does 750,000 noop requests/second. And X wouldn't be feasible
if operations took long to complete: in fact, web servers have the problem
of long to complete operations (they may one or more disk accesses).
Why X sometimes seems slow are the cross product of:
a) bad implementations
b) graphics requests that may touch a large number of pixels
c) the naive schedular that Keith's been changing for XFree86
so that a bunch of batched b) requests won't cause the server to
work so long for a single client.

HTTP protocol behavior depends VERY strongly on both client and server
buffering implementation details, and on the content (e.g. applications).
What (almost all) current clients do is a far cry from what they could/should
do.

In fact, Apache's output buffering is quite good: the problem is that
the clients don't do goo request generation; if the server doesn't get
the requests in a batch, it will tend to degenerate back toward HTTP/1.0
behavior.

> > And, btw, HTTP/1.1 with suitable clients does batching similar to what
> > X does, and may show more similar behavior than it has in the past (the
> > clients still aren't all that good at exploiting what is possible in
> > the HTTP/1.1 protocol).
>
> The dumps I've seen dont back this up. Its not an HTTP/1.0 or 1.1 thing. You
> spend most of your time wondering when the other guy will do something. He's
> generally on a modem/isdn. He queries you, you crap 40K down the socket, you
> dont here form him until the next request. if its an 80K image you get
> woken a few times to lob another 20K in. Its purely bandwidth. If it was
> 40 instances of Miguel reading web pages flat out over 100baseT you would
> definitely be right. But its not...

Most current clients don't do any rational buffering of requests, and
don't begin to drive TCP well. Even on dialup lines, doing all
this properly can make a significant performance difference (though dialups
benefit most from use of stylesheets etc. So if you look at today's behavior
by deployed clients, you'll see very poor behavior.

In particular, look at our SIGCOMM paper and some of the other notes
we've put out, which you can find at:

http://www.w3.org/Protocols/HTTP/Performance/

So I note: the web protocol is changing
the web content is changing
Moral: *don't* extrapolate current web server performance bottlenecks
too far into the future. Its all going to be different again...

- Jim

-
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:55    [W:0.720 / U:0.008 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site