[e2e] Number of persistent connections per HTTP server?

[Venkat Padmanabhan]

> Venkat Padmanabhan wrote:
> > I believe the reason the recommended number of persistent
connections
> > per client was set to 2 rather than 1 was to prevent head-of-line
> > blocking. With a single connection (and in the absence of byte-range
> > requests), the transfer of a large object could block subsequent
> > requests for a significant length of time. With two connections, one
can
> > confine the large transfers to one connection, keeping the other one
> > clear for short transfers. This is analogous to why a two-lane road
is
> > far better than a single-lane one.
> 
> Hi, Venkat (et al.),
> 
> That would make sense if clients managed the connections that way.
> However, they often take the first idle connection for each pending
> request; i.e., it's like watching trailers passing each other slooowly
> while the cars backup behind.

Joe,

You are probably right, but I guess it is not surprising that there is
disconnect between the intention of the designers and the engineering
choice made in practice... Also, the simpler engineering choice may
still offer much of the benefit of having two connections if large
transfers are few and far between (so that the likelihood of two of them
happening simultaneously is small). 


> 
> Besides, how is the client to know what a short request is vs. a long
> one? Sometimes even the server doesn't know (when the reply is sent in
> chunks)...

Good question. I guess the client could use an HTTP HEAD request to
determine the object size beforehand. While this would only work for
static content, that wouldn't be so bad in practice since large objects
are likely to be static anyway. 

-Venkat