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 Wed, 04 Jan 2017 17:28:46 GMT
Hi Kyriakos,

sorry for not replying earlier. I could find the issue you ran into, namely that mod_http2
is obsessed with the streams it already has and does not submit ready responses - until the
existing streams are done or pause.

I hope that the new release works much more nicely for you. You find it at https://github.com/icing/mod_h2/releases/tag/v1.8.7

Thanks,

Stefan

> Am 02.01.2017 um 23:33 schrieb Kyriakos Zarifis <kyr.zarifis@gmail.com>:
> 
> Thanks Stefan!
> 
> I just tried the tweaked version. I think I am seeing similar behavior, i.e. the higher-prio
HTML reply is sent ~500ms after its request is received, writing ~500 lower-prio DATA frames
(~7.5MB) in the meantime.
> 
> Before any conclusions, I wanted to make sure I compiled/used the tweaked mod properly
with my existing Apache/2.4.25 on Ubuntu, since I haven't done the process before: I couldn't
find details on the right way to swap in/out module versions, so I ended up compiling v.1.8.6
and pointing to the created mod_http2.so in "/etc/apache2/mods-enabled/http2.load", but I'm
really not sure that's the right way. The only way I verified it was seeing this in /var/log/apache2/error.log:
> 
> "[http2:info] [pid 24935] AH03090: mod_http2 (v1.8.6-git, feats=CHPRIO+SHA256+INVHD,
nghttp2 1.17.0), initializing..." 
> 
> 
> Assuming this is an acceptable way to use the tweaked version of the module (please let
me know if not), where should I share two apache log files (one trace for each module version)
so you could verify what I see?
> 
> 
> 
> 
> A few relevant lines from the v1.8.6 run (similar to the stable module, AFAICT):
> 
> [Mon Jan 02 13:59:59.636519 2017] [http2:debug] [pid 26718] h2_session.c(439): [client
] AH03066: h2_session(0): recv FRAME[HEADERS[length=39, hend=1, stream=19, eos=1]], frames=13/1721
(r/s)
> [Mon Jan 02 13:59:59.637099 2017] [http2:debug] [pid 26718] h2_task.c(106): [client ]
AH03348: h2_task(0-19): open output to GET  /preposition/nextnav.html
> 
> [ ... continue sending ~500 DATA frames for streams 7-11 ...]
> 
> [Mon Jan 02 14:00:00.177350 2017] [http2:debug] [pid 26718] h2_session.c(661): [client
] AH03068: h2_session(0): sent FRAME[HEADERS[length=87, hend=1, stream=19, eos=0]], frames=16/2209
(r/s)
> [Mon Jan 02 14:00:00.177366 2017] [http2:debug] [pid 26718] h2_session.c(661): [client
] AH03068: h2_session(0): sent FRAME[DATA[length=456, flags=1, stream=19, padlen=0]], frames=16/2210
(r/s)8.6
> 
> [ ... continue sending streams 11 onwards ...]
> 
> Thanks!
> 
> On Sat, Dec 31, 2016 at 5:43 AM, Stefan Eissing <stefan.eissing@greenbytes.de>
wrote:
> Hi Kyriakos,
> 
> have a look at https://github.com/icing/mod_h2/releases/tag/v1.8.6
> 
> That version flushes when at least 2 TLS records are ready to send. Also, frame sizes
are now aligned to TLS record sizes. So they are influenced by the H2TLSWarmUpSize and H2TLSCoolDownSecs
settings.
> 
> Additionally, and highly experimental, I added H2TLSFlushCount to configure the number
of records to flush. You may play around with it (default is 2) in your scenarios.
> 
> I hope that this reduces buffering and makes the server more (another word for agile,
pls) to stream changes. Please let me know if that had any effect on your tests.
> 
> Thanks,
> 
> Stefan
> 
> > Am 29.12.2016 um 12:40 schrieb Kyriakos Zarifis <kyr.zarifis@gmail.com>:
> >
> > That means the images should get a minim of ~30% of the available bandwidth as long
as they have data. My reading.
> >
> > Right. Makes sense.
> 
> Stefan Eissing
> 
> <green/>bytes GmbH
> Hafenstrasse 16
> 48155 Münster
> www.greenbytes.de
> 
> 

Stefan Eissing

<green/>bytes GmbH
Hafenstrasse 16
48155 Münster
www.greenbytes.de


Mime
View raw message