Re: HTTP Working Group 'issues' list

> > Actually, preliminary tests with Apache would seem to indicate that the
> > user's perceived performance improves on a keep-alive'd server if the
> > number of simultaneous connections is set to 2 versus 3 or 4 or 1.
> Having at least two pipes open probably creates a "fast" path, which
> becomes used for short documents, thus improving the perceived
> latency.
> > That is in addition to a dramatic decrease in server load.
> > I think it is due to slow start and the cost of squeezing multiple requests
> > through a single pipe, but these tests were only preliminary.
> The "slow start" motivation does not seem appropriate to me.  I
> don't believe you are allowed to send a second request on a persistent
> connection before you get a complete reply. Thus the client -->
> server direction almost surely incurs in a slow start, as can be
> seen by the following piece of code in tcp_output.c (4.4BSD):
>                 /*
>                  * We have been idle for "a while" and no acks are
>                  * expected to clock out any data we send --
>                  * slow start to get ack "clock" running again.
>                  */
>                 tp->snd_cwnd = tp->t_maxseg;
> In practice, if the request is shorter than an MSS there is no
> effect, otherwise it takes an additional RTT just to send out the
> request (the importance of headers being small...).
> On the reverse path, a similar thing might occur because subsequent
> responses are separated by the following events:
> 	+ client realizes the reply is complete
> 	+ the request reaches the server (1/2 RTT)
> 	+ the server parses the request and accesses the
> 	  document
> and, especially on a busy server, the latter might cause a significant
> delay thus triggering a slow start.

Can anybody confirm the following: is the keep-alive connection
only a chain of "request-reply" between a client and ONE instance of
a server ?

So the discussion seems to be "fork less processes that live longer,
thus eating more memory and maybe other resources" against "fork more
processes that only do one reply and thus die earlier". Is this correct ?

> 	Luigi
> ====================================================================
> Luigi Rizzo                     Dip. di Ingegneria dell'Informazione
> email:       Universita' di Pisa
> tel: +39-50-568533              via Diotisalvi 2, 56126 PISA (Italy)
> fax: +39-50-568522    
> ====================================================================
Carlos Horowicz
Ministry of Foreign Affairs - ARNET
Buenos Aires, Argentina

Received on Thursday, 15 February 1996 12:43:18 UTC