httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Eissing <stefan.eiss...@greenbytes.de>
Subject Re: HTTP/2 frame prioritization not honored
Date Thu, 29 Dec 2016 09:55:07 GMT

> Am 29.12.2016 um 02:07 schrieb Kyriakos Zarifis <kyr.zarifis@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





Mime
View raw message