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.zari...@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.eiss...@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.zari...@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
