W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > May to August 1998

Re: Advantages of persistent connections

From: Jim Gettys <jg@pa.dec.com>
Date: Mon, 15 Jun 1998 09:59:18 -0700
Message-Id: <9806151659.AA05788@pachyderm.pa.dec.com>
To: Telford001@aol.com
Cc: martin-flatin@epfl.ch, http-wg@cuckoo.hpl.hp.com, Bodzia@aol.com

> From: Telford001@aol.com
> Resent-From: http-wg@hplb.hpl.hp.com
> Date: Sun, 14 Jun 1998 23:08:24 EDT
> To: martin-flatin@epfl.ch, http-wg@cuckoo.hpl.hp.com
> Cc: Telford001@aol.com, Bodzia@aol.com
> Subject: Re: Advantages of persistent connections
> -----
> In a message dated 98-06-14 19:43:03 EDT, martin-flatin@epfl.ch writes:
> 
> > Regarding the advantages of persistent connections listed in section
> >  8.1.1, under heading "Persistent HTTP connections have a number of
> >  advantages", one is missing (latency), and one is not always true (memory
> >  savings). I therefore suggest 2 changes.
> 
> >  1) Add a bullet between current 3rd and 4th bullet:
> 
> >      .  Latency is reduced because network congestion is reduced, so
> >         less retransmissions are needed, so the elapsed transmission
> >         time is shorter.
> 
> >  2) Replace:
> 
> >      .  By opening and closing fewer TCP connections, CPU time is saved,
> >         and memory used for TCP protocol control blocks is also saved.
> 
> >  with:
> 
> >      .  By opening and closing fewer TCP connections, CPU time is saved
> >         in routers and hosts (clients, servers, proxies, gateways, tunnels,
> >         or caches), and memory used for TCP protocol control blocks can
> >         be saved in hosts.
> 
> >  Regarding memory savings, the original statement is not true in its
> >  generality. The number of TCP control blocks using up memory at any point
> >  in time depends on many parameters, among which we find:
> 
> >  * timeout value of persistent connections
> >  * average number of simultaneous users
> >  * activity of users:
> >      - whether they typically retrieve lots of objects (pages, inline
> >        images) and then become quiet
> >      - whether they typically download a few objects every N minutes
> >        with N inferior to the TCP connection timeout value
> >      - whether they typically download a few objects every N minutes
> >        with N superior to the TCP connection timeout value
> >      - whether they typically poll a server (e.g., to get the latest
> >        results of a sporting event)
> >  * etc.
> 
> >  By varying these values, one can easily show that the number of TCP control
> > blocks can be higher with persistent connections in some cases, smaller in
> > others. Persistent connections often allow to save memory, but not always.
> 
> I am not sure exactly what is meant by CPU time, but as pointed out
> persistent connections do not correlate with opening and closing fewer
> TCP connections.  In fact persistent connections may result in greater
> search times for protocol control blocks as the number of active protocol
> control blocks in many sorts of typical types of web use will increase
> with persistent TCP connections.

Not true; please see Jeff Mogul's research in this area; since there are 
many fewer connections used, you have many fewer PCB's in time-wait state 
after the connections close, so research  (using traces) indicates that 
fewer total PCB's are needed.
> 
> Telford Tools does a lot of work in optimizing web server performance.
> We have the impression that the use of persistent TCP
> connections for HTTP was addressing the problem of the excessive
> cost of opening a TCP connection in certain TCP implementations. 
> 
> As the use of persistent TCP connections is not guaranteed
> to decrease the number of TCP connections opened per
> second in typical web server or usage (although
> the number of connections opened per second in certain
> performance tests may decrease), the persistent TCP connection
> feature while relatively harmless is irrelevant to Web Server
> or Web Client performance except in certain contrived
> situations.  In many situations persistent TCP connections
> will not decrease the number of connections opened per
> second but will decrease the number of http transactions
> per second of which a given servier is capable because
> at any given time the time to find a protocol control block
> may in crease because the number of active protocol
> control blocks at any given moment is likely to increase
> with the use persistent TCP connections.
> 
> In the general case, if better Web Server
> or Web Client performance is desired, the correct
> approach is to bite the bullet and improve the performance
> of the TCP virtual circuit open code.
> 

I have no problems with optimizing code, wherever....

I think you'll find others who've been looking into this problem
carefully hold other opinions to those you state in this message...

Joachim, I think you need to read some of the research papers that
made the case for HTTP/1.1; you'll find them referenced at the
end of the HTTP spec.   They include simulations of the effects of
persistent connections on TCP PCB's, and some running code work
that we've done as well.
				- Jim
Received on Tuesday, 16 June 1998 09:22:30 EDT

This archive was generated by hypermail pre-2.1.9 : Wednesday, 24 September 2003 06:33:19 EDT