> Am 29.12.2016 um 02:07 schrieb Kyriakos Zarifis <kyr.zari...@gmail.com>: > > I am experimenting with contention between lower/higher priority HTTP/2 > streams, and I think I am noticing that high-priority frames are not given > high priority (quickly enough) > > The process is: Download dummy page A, which, after onLoad, Prefetches 8 > objects (5MB each) at low priority. While the first few of those are > downloaded, click on link to page B (high priority stream), and measure how > long it takes to receive. > > The client-server RTT is 20ms, and ideally because of higher prioritization > we would want the second HTML to be received at a timeframe as close to that > RTT as possible. However, I am noticing that the second HTML is delayed > (although not completely HoL-blocked) by objects that are being Prefetched at > lower priority. > > This plots the client-side trace (Chrome log): HTML A is stream_id 1, the 8 > prefetched objects are streams 3-17, and HTML B (the object that is delayed) > is stream_id 19. Dots below the x axis are the GET requests for the > respectively colored streams. Dots above the x axis are received DATA frames. > GETs for the prefetched objects are sent after onLoad, and that of stream_id > 19 is sent when I click on the link, around t=1900. As this shows, the reply > for the high-priority stream (19) arrives ~1.5s later. > > Apache's log shows that it sent the reply to stream_id 19 (HTML B) ~500ms > after it got its request. During those 500ms, it wrote another ~350 frames > (~5MB) from other streams. So it honors the higher priority in the sense that > it interleaves the HTML between the currently written object, but it > continues to write many lower-priority frames before it does so, delaying > that high-prio HTML. In contrast, when I wait until all prefetched objects > are served and then click on the link, the logs shows that the reply is > written within a few ms from the request arrival, as expected, and the second > page loads observably faster. > > This seems to break any default prioritization or prioritization imposed by > the client, and leads to unexpected performance in different > prioritization-dependent scenarios that I have tried. > > Has anyone experience this before, and do you know what causes it and what > the right way to fix it would be?
Reading your excellent description, there are two main things that can affect this: 1. priority dependencies: streams with lower prio, but depending on a high level stream, inherit this priority. This would make all preloads *together* have the same prio as page B. Last I knew, chrome did no dependencies. Were these resources PUSHed by the server? 2. mod_http2 is, in its current implementation, very eager to fill the core network buffers. That means a lot of frames have already been pre-packaged for sending before page B becomes ready to sent. These are then not pre-empted by page B, but will be sent first. If you are willing to test a github beta of the module, I might find the time next week to tweak the behaviour in 2) and you could verify the benefits in your setup. I will not promise anything, though. -Stefan
