- From: patrick mcmanus <pmcmanus@mozilla.com>
- Date: Mon, 30 Jul 2012 08:37:05 -0700
- To: ietf-http-wg@w3.org
On 7/29/2012 11:32 PM, Henrik Frystyk Nielsen wrote: > Martin, > > What scenarios do you have in mind where pipelining does not work? Obviously it only works for GET so for web sites using lots of non-GET requests it won't work but GET is the predominant method on most sites. I'm a believer that we can get more benefit from pipelines than we currently do, and I remain committed to seeing that happen on today's http/1 web. But the challenges go beyond non-get and mangling intermediaries(*).. so in a pro-pipeline, but eyes-wide-open spirit: 1] you still need parallelism because of priority head of line blocking issues. But now some of the parallel flows are filling the pipe and buffers very well, and its hard to manage the prioritization effectively. Using a priority mux instead of pipeline+parallelism makes that work a bit better (buffering in the network remains a problem - though with fewer connections they should at least not be filled as deeply) 2] even on get - blocking responses are common and they screw up the pipeline. database operations, web service callouts, etc all can create variability in response times, and that creates time-to-utilization gaps 3] http/1 cancellation semantics don't exist other than closing the connection, and pipelines make this worse. This comes up all the time in the form of links clicked on partially rendered pages. (think "next" on a webmail inbox). To process the click you need to decide between waiting for the old one to drain, adding more to its existing pipeline, or making a new connection.. this problem always existed without pipelines but the amount of data in the queue has now gone up. [*] in my experience the most significant intermediary challenges these days come from AV and firewall software.. actual network devices and servers fair ok with a couple notable exceptions. I don't know that this makes it any easier :) pipelines are useful things - but I think we can do better than just working around their warts. > > We took some pretty normal sites so I do think they represent reasonable data. We'd be happy to expand the sites but the whole point was to show differences in relatively common sites. It is correct that we didn't use cookies. Cookie and UA-header sizes can indeed vary a lot but that is a much more isolated problem to solve that can be done in any number of ways. cookies and pipeline performance are pretty tightly tied. Pipeline depth is driven by client cwnd and the difference in pipeline depth on a cold TCP session goes from 10 to 2 as cookie sizes go from 0 to 2KB. An HTTP/2 approach that removes header redundancy (whether that be by some manual table approach like network-friendly, or a automagic gzip approach like spdy) is critical to addressing the fundamental round trip problem. cheers, -Patrick
Received on Monday, 30 July 2012 15:37:43 UTC