[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [patch] TUX 2.4.2-P3 (fwd)



more detailed info on keep-alive timeouts.  i misremembered the report :)

-dean

---------- Forwarded message ----------
From: Jeffrey Mogul <mogul@pa.dec.com>
To: Jim Gettys <jg@pa.dec.com>
Cc: dean gaudet <dean@arctic.org>, mogul@pa.dec.com
Subject: Re: [patch] TUX 2.4.2-P3 (fwd)
Date: Mon, 12 Mar 2001 13:01:25 -0800
X-Mts: smtp

    I believe it is Jeff Mogul's work...

Right:
    Jeffrey C. Mogul. The Case for Persistent-Connection HTTP. In Proc.
    SIGCOMM '95 Symposium on Communications Architectures and
    Protocols, pages 299-313. Cambridge, MA, August, 1995

There's a technical-report version available as well:
    Jeffrey C. Mogul. The Case for Persistent-Connection HTTP. Research
    Report 95/4, Digital Equipment Corporation Western Research
    Laboratory, May, 1995.
    http://www.research.digital.com/wrl/techreports/abstracts/95.4.html
or  http://www.research.compaq.com/wrl/techreports/abstracts/95.4.html

However, Dean wrote:

> there's a study by some folks at DEC years ago which showed that anything
> more than a minute is overkill.  sorry i don't have a reference to it any
> more.  i'll see if i can dig something up.

this mischaracterizes the work.  In fact, it depends on what
aspect of performance you are trying to optimize, and what
maximum number of connections your server will support.  In
some cases, my study showed significant benefits for timeouts
well over a minute.  (Note that this was based on traces made
in 1994, so I would also not recommend basing any blanket statements
about timeout values on this particular study!)

The bottom line (in my opinion) is that the *server's* timeout should
not be the primary mechanism for deciding when to close a connection.
Instead, the server should strive to keep as many connections open
as possible (within resource constraints: vanilla Apache is badly
structured for keeping lots of connections open), and then close
connections *as necessary* based on how long they have been idle.
This approach adapts to the conditions of the current situation,
whereas a fixed timeout cannot.

It would be nice if someone could do some actual testing on
a live, busy Tux server to see how various metrics actually
depend on the choice of timeout values.  Of course, some of
these metrics have to be measured at the client!

    And yes, previous studies show that it is probably not wise for clients
    (or less so servers) to keep connections open indefinately: it becomes
    likely that a client is off doing something else.

I believe that my paper recommended that a client should, in fact,
close its connections to a server if it does go "off doing something
else."  For example, drop a connection if you no longer have any
open windows for the server, or if there has been no user activity
(including, perhaps, server-specified auto-refreshes) over a number
of minutes.

    It would be best if we could hint to clients to close connections,
    so that the client (almost) always did the close to avoid FIN's...
    Unfortunately, while we discussed such mechanisms, we never finished
    defining one.

Browser vendors have been remarkably immune to taking our advice
on how to optimize the use of the network and the servers.  I'm
not sure that adding an optional mechanism to HTTP would have
decreased their resistance.

> fwiw, apache never generates the 408 response.  in fact i don't see
> anything in rfc2616 which says it MUST be generated (i don't see any
> mention of response code 408 except for the short blurb defining it).
> clients can't assume it would be generated -- otherwise they'd not
> interoperate with HTTP/1.0 keep-alive implementations.  they have to
> assume that if they don't get a response back for a request then the
> server didn't process it.

My memory about 408 isn't very good, but I don't think this is
related to the persistent-connection stuff at all.  Even in
the single-request-per-connection model, a client might open
a connection but then fail to successfully transmit the request
to the server (maybe not the client's fault - networks do fail,
on occasion) and this was added as a "clean" way to tell the
client "whatever you sent me, I didn't do it, so you can try
again without fear that you are going to repeat an operation
that has side-effects."  E.g., think about a request that
says "donate $100 from my bank account" - not that HTTP should
be used for financial transfers, but in this situation, the
client ought to know whether or not the server actually received
the request.

-Jeff







[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index] []