httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kyriakos Zarifis <kyr.zari...@gmail.com>
Subject HTTP/2 frame prioritization not honored
Date Thu, 29 Dec 2016 01:07:29 GMT
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 <https://plot.ly/~kyriakos/95266/chrome-trace-tcp-notsent-lowat-1/> 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?

Thanks

Mime
View raw message