- From: Jamie Lokier <jamie@shareable.org>
- Date: Thu, 22 Oct 2009 01:57:51 +0100
- To: Adrien de Croy <adrien@qbik.com>
- Cc: Jim Gettys <jg@freedesktop.org>, "William A. Rowe, Jr." <wrowe@rowe-clan.net>, Mark Nottingham <mnot@mnot.net>, HTTP Working Group <ietf-http-wg@w3.org>
Adrien de Croy wrote: > Jim Gettys wrote: > >We showed in the HTTP/1.1 paper that additional parallel connections > >did not actually increase performance; fastest performance was > >achieved with a single TCP connection. But for many bad > >implementations, doing so will, without the implementers having to > >actually think or restructure their code. > > > > > depends on how you define performance. Agreed for the case where you > are making a single HTTP request to download a large resource. > > But for a site with a large number of embedded images or parts (common > nowadays for a home-page to result in well over 100 requests), then > serializing requests + latency results in a poor user experience. > Opening multiple connections and making concurrent requests greatly > improves user experience. That's why browsers do it. This is precisely why I keep advocating multiplexing over on the hybi list, if anyone is subscribed to both... Multiple connections reduces aggregate throughput (mostly), but improves the user experience because of the concurrent arrivals. Resources taking a long time to generate on the server, and large resources, don't block the arrival of other resources so much. Good multiplexing can provide a combination of both - maximal throughput using few or one TCP connection, at the same time as concurrency. Which is why HTTP-over-SCTP is being looked at (it is multiplexing done better than TCP can). But even over TCP it has potential. -- Jamie
Received on Thursday, 22 October 2009 00:58:30 UTC