I'm assuming that the brokenness also shows up on trunk, right? Bert, Jan, can you check if trunk shows the same behavior? I would prefer not hacking away on 2.4 directly and independently.
tia!! > On Nov 29, 2015, at 3:03 AM, Stefan Eissing <stefan.eiss...@greenbytes.de> > wrote: > > Ok, thanks. I think I have an idea of what's happening: > - on short request bodies, window updates get omitted and gives a shrinking > connection window > - the window size of the connection itself should be at max Value right from > the start > > I won't be able to do anything about it until later this week, though. > > //stefan > > Am 28.11.2015 um 22:29 schrieb Bert Huijben <b...@qqmail.nl>: > >>> -----Original Message----- >>> From: Bert Huijben [mailto:b...@qqmail.nl] >>> Sent: zaterdag 28 november 2015 14:32 >>> To: stefan.eiss...@greenbytes.de; dev@httpd.apache.org >>> Subject: RE: No H2 Window updates! >> >> >>> In case of Subversion's real usage, I want to commit potentially hundreds >> of >>> MByte, so a connection level window of more than a few bytes would be >>> very >>> welcome.... With HTTP/1 we send out the data as fast as we can and the TCP >>> windowing handles this from the httpd side... Now the http/2 level >>> windowing >>> should handle this. >>> >>> >>> Mod_dav and mod_dav_svn are usually fast readers; just limited by trivial >>> disk io or xml processing in the common operations, so I don't expect real >>> problems there. >> >> For my commits against the svn-master.apache.org repository my latency/ping >> time is +- 142 ms. >> >> With the current simple algorithm and a maximum window of 64 >> Kbyte/connection, I can send a theoretical maximum of 64 Kbyte/142 ms per >> connection to that server... which would be about 450 Kbyte/s. >> (=1/0.142*65536/1024) >> >> That is < 1/30th of the bandwidth I have at my disposal (+- 150 Mbit). >> >> But currently I don't even get anywhere near that as my window continues to >> shrink because some data is missed in accounting even after my simple patch. >> >> >> >> For httpd we have to think carefully which algorithm we want to implement >> here. Preferably the algorithm should be better than TCP could, as we know >> the specifics of the http algorithm better than plain TCP could for >> HTTP/1,1. TCP does send a lot of window updates though... Almost every >> packet does. >> >> >> Solving the really hard problems, like this one, is the reason I didn't >> think the nghttp2 library would really be the solution for serf. >> It is nice for such a library to provide a head start on the protocol level, >> but there is no way a standard library can really solve this scheduling >> problem in a generic way. (If it could do it, we had used that solution for >> TCP... and never had to resort to designing a HTTP/2 in the first place). >> >> See https://en.wikipedia.org/wiki/TCP_window_scale_option for some >> introduction on how TCP was extended to work above the limit that currently >> applies to H2. >> >> >> Dynamic window sizing/scaling will have to be implemented at some point, at >> both the stream and the connection level... This will involve timing, >> measuring, etc. etc. Things nghttp2 can't do for us right now. >> And if I'm right this might take continuous optimizing for years to come. >> >> >> >> When I connect to sites like google I immediately receive a large connection >> level window, to allow me to post huge blobs without a delay. (Haven't >> tested their stream level windows behavior yet) >> In serf I do something similar... and then apply a bit of throttling at the >> stream level. >> >> >> I would guess some clients have already implemented some of this, so we >> might be able to learn from their implementations... Clients will see much >> more incoming data than servers of course :). >> >> >> Bert >> >>
