[opensource-dev] New HTTP Library & Project Viewer

[Oz Linden (Scott Lawrence)]

On 2012-07-29 13:58 , Sheet Spotter wrote:
> Does increasing the HTTP connection limit also increase the burden on the
> server and network?
>
> Increasing the HTTP connection limit on one client might improve the
> experience for one person. It might also diminish the experience for
> everyone else on the same server.

Exactly so.  The effect is more complex than just consuming file 
descriptors on the server side, as well.  TCP congestion control works 
far better when dealing with a smaller number of connections. Any 
packets that are not subject to congestion control that are sharing the 
same network path as a TCP connection increase the likelihood of a 
dropped packet in the connection flow, which causes the connection to 
immediately cut its transmission window by half. The viewer already puts 
a lot of UDP traffic into the same path. The handshake packets that open 
and close TCP connections are also not subject to the congestion control 
- which means that opening each new connection increases the chances 
that each of your existing connections will slow down by half.  Opening 
many connections also puts additional strain on routers in the path that 
are doing connection tracking (which too many do), adding another 
possible source of problems.

In general, when persistent connections and pipelined requests (having 
more than one request in flight on a connection at a time) are used, 
HTTP performs far better with a small number of connections than with 
more.  As we begin deploying support for this way of using it on the 
server side, we'll be able to do good experiments to determine what the 
right tradeoffs are for network behavior and server load to provide 
optimal experience for users.