Re: HTTP Session Extension draft

    CASE 2 --  Want to grab "initial.html".  Client yet has no clue whether
    document contains inline images.  My opinion: I question whether making
    a persistent connection here is valid, especially if the user has
    requested inline images not to be sent.
    
    CASE 3 -- Want to grab "initial.html".  User doesn't load inline
    images, but client guesses that the user will be so enamored with this
    document that they might want to click on another document from the
    same server.  My opinion: I think the client is out of line holding a
    connection open on a server solely for this reason.  Doesn't an extra
    connection mean an extra process and an extra copy of the server
    program in memory for many servers?  What a waste!  Now people who are
    making legitimate connections with real requests get slower performance
    while the server swaps memory to disk.  Maybe next rude clients will
    hold open connections on documents 3 layers deep in their history, just
    on the off chance a user might go back to it and start clicking again.

You raise legitimate concerns.  However, the results of my simulations
(based on traces from actual clients and actual servers) indicate that
you can probably stop worrying.

Since I looked at the requests coming from actual clients, my traces
already account for "are the inlined images already cached?".  That
is, I only looked at client-cache misses.

My simulations assumed that EVERY connection request should be treated
as a persistent connection.  That is, I did not try to simulate any
cleverness on the client's part.  This means that clients were using
persistent connections to handle all three of your cases.

The results show that, even with very conservative limits on the
number of open connections at the server (hence, limits on the
number of server processes) and even with this "greedy client"
approach, persistent connections still avoid lots of overhead.
In particular, they *reduce* the amount of server memory required
to store TCP connection tables.

In other words, it DOES pay to keep the connection open "on the off
chance a user might go back to it and start clicking again."  Users
do this often enough to pay off.

Read the paper for full details.

-Jeff

Received on Monday, 10 July 1995 16:09:51 UTC