httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Eissing <>
Subject Re: HTTP/2 frame prioritization not honored
Date Thu, 29 Dec 2016 11:26:11 GMT

> Am 29.12.2016 um 12:10 schrieb Kyriakos Zarifis <>:
> 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?
> Not PUSHed; they were requested by the browser upon A's onLoad using the ' link rel=”prefetch”
' directive in HTML A's <head>.
> Right, I forgot to add this in the description: Chrome's log shows the priorities/dependencies
as follows:
> HTML A : stream_id=1, parent_stream=0, weight=256
> 1st Prefetched image : stream_id=3, parent_stream=0, weight=110
> 2nd Prefetched image : stream_id=5, parent_stream=3, weight=110
> 3nd Prefetched image : stream_id=7, parent_stream=5, weight=110
> ...
> 8th Prefetched image : stream_id=17, parent_stream=15, weight=110
> HTML B : stream_id=19, parent_stream=0, weight=256
> So my understanding was that the dependencies looked reasonable, i.e. the prefetched
objects form a separate lower priority chain starting at the root and as such should not block
anything with higher prio with the same parent (0). Am I reading this correctly?

That is different than Firefox is doing things, but it should work. Notice though, that the
images are chained with weight 110 on stream 0 and HTML B with max weight 255. That means
the images should get a minim of ~30% of the available bandwidth as long as they have data.
My reading.

> 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.
> This was my (as well as a few Chrome devs') guess, especially considering that HTML B
is not blocked behind the prefetched images (in fact not even blocked by completing any single
one of them: the images are sent serially and HTML B is correctly interleaved between frames
of one of those images - it just doesn't seem to happen as quickly as it could have (~500ms
earlier, in this particular case) ).
> I'd be really interested in repeating the experiment with a tweaked version of the module.
Please feel free to let me know if/how I can help.

I see what I can come up with. Thanks!

> Thanks,
> Kyriakos
> -Stefan

Stefan Eissing

<green/>bytes GmbH
Hafenstrasse 16
48155 Münster

View raw message