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

Re: Advantages of persistent connections

From: <Telford001@aol.com>
Date: Sun, 14 Jun 1998 23:08:24 EDT
Message-Id: <cd5712c.35849029@aol.com>
To: martin-flatin@epfl.ch, http-wg@cuckoo.hpl.hp.com
Cc: Telford001@aol.com, Bodzia@aol.com
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.

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.

Joachim Martillo
<A HREF="http://members.aol.com/Telford001/">Telford Tools, Inc.</A> 
Received on Sunday, 14 June 1998 20:23:55 EDT

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