Hi Stefan, Yes, this is making a big, obvservable difference!
Specifically, in all 3 repeats, the high priority stream is now served 100ms after it was received, writing ~100 frames (~1.6MB) of currently served, lower-priority stream. (was: 500ms, 500frames(~7.5MB)) In more detail, after the high-prio request is received, 20 more low-prio frames are served before the h2_task for it logs that it opens the output for the new stream. Then, another 80 low-frames are served before the high-prio reply is written. (relevant logs below) This already has an observable impact on the transition to the next page the moment I click on the link (goes from 1.5sec to less than 500ms), which I think is great because this tweak is relevant not just to this scenario, but to any higher level stream that begins while lower ones are served, even within a single page. I'm wondering if the change you made can be pushed harder to make the switch to the new stream even faster, e.g. avoiding even those 100 frames? Thanks, Kyriakos [Wed Jan 04 10:14:48.577687 2017] [http2:debug] [pid 24864] h2_stream.c(213): [client] AH03082: h2_stream(0-19): opened [Wed Jan 04 10:14:48.577758 2017] [http2:debug] [pid 24864] h2_session.c(452): [client] AH03066: h2_session(0): recv FRAME[HEADERS[length=39, hend=1, stream=19, eos=1]], frames=13/1486 (r/s) 20 x lower-prio frames: [Wed Jan 04 10:14:48.577864 2017] [http2:debug] [pid 24864] h2_session.c(685): [client] AH03068: h2_session(0): sent FRAME[DATA[length=16275, flags=0, stream=5, padlen=0]], frames=16/1486 (r/s) [Wed Jan 04 10:14:48.578775 2017] [http2:debug] [pid 24864] h2_task.c(106): [client] AH03348: h2_task(0-19): open output to GET 204.57.7.200 /preposition/nextnav.html 80 x lower-prio frames: [Wed Jan 04 10:14:48.578790 2017] [http2:debug] [pid 24864] h2_session.c(685): [client] AH03068: h2_session(0): sent FRAME[DATA[length=16275, flags=0, stream=5, padlen=0]], frames=16/1504 (r/s) [Wed Jan 04 10:14:48.682168 2017] [http2:debug] [pid 24864] h2_session.c(685): [client] AH03068: h2_session(0): sent FRAME[HEADERS[length=87, hend=1, stream=19, eos=0]], frames=16/1587 (r/s) [Wed Jan 04 10:14:48.682186 2017] [http2:debug] [pid 24864] h2_session.c(685): [client] AH03068: h2_session(0): sent FRAME[DATA[length=456, flags=1, stream=19, padlen=0]], frames=16/1588 (r/s) On Wed, Jan 4, 2017 at 9:28 AM, Stefan Eissing <stefan.eiss...@greenbytes.de > wrote: > 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 > >
