Re: HTTP Session Extension draft

    Well the first thing to keep in mind is that those same busy servers
    are keeping 1000 records for closed connections that are in the
    time-wait state.
    
Not necessarily.  My simulations, using traces from several busy servers,
show that with certain choices of server parameters, the peak number of
TIME_WAIT entries is well below 1000.  That is, the use of sessions
can actually reduce the number of TIME_WAIT entries by an order of
magnitude (compared to non-session HTTP).  More details in my SIGCOMM
paper, or look at
    http://www.research.digital.com/wrl/publications/abstracts/95.4.html

The reason is that the number of TIME_WAIT entries is directly related
to the number of TCP connections used.  If you use sessions (what I
called in my paper "persistent connections"), you need to create fewer
TCP connections for the same number of retrievals.  So you end up
with fewer TIME_WAIT entries.

The total number of TCB table entries is roughly A+T+F, where T
is the number of TIME_WAIT entries, A is the number of active
connections, and F is a fudge factor to account for connections
in short transitional states.  For standard HTTP, in the cases
I've looked at, F is actually larger than A but much smaller than T.
For persistent-connection HTTP, F is probably fairly small (but I
didn't simulate it).  Anyway, the total A+T seems to be smaller
with persistent connections; even though A is larger, T is much
smaller.

    Note that I am not advocating irresponsible use of sessions, although
    it would make sense to me that a clinet might request a session for
    every HTTP request that it makes under the assumtion that 90% of HTML
    pages have some images on them. And if they dont, you just close the
    connection as soon as you have recevied it anyway.

I don't understand how the term "irresponsible" applies here at all.
I frankly don't see any situations where the use of persistent
connections can cause any problems (under the assumption that any
party can terminate a connection whenever it wants to free up the
resources).

I also suspect that much of the benefit comes NOT from imbedded
images, but from subsequent requests for HTML pages (i.e., the 
user clicks, reads, and clicks again).  My simulations showed
that a substantial fraction of the connection-reusing retrievals
were only captured if the server's idle-connection timeout is
longer than 10 seconds.  This implies that the connection is
capturing several distinct requests, not just retrievals of
images.  However, past 100 seconds or so, there is relatively
little improvement.  I.e., a user who hasn't asked for something
in two minutes isn't likely to ask any time soon.

-Jeff

Received on Thursday, 6 July 1995 10:40:51 UTC