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 > >
