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