httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Eissing <stefan.eiss...@greenbytes.de>
Subject Re: No H2 Window updates!
Date Sun, 29 Nov 2015 08:03:52 GMT
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 <bert@qqmail.nl>:

>> -----Original Message-----
>> From: Bert Huijben [mailto:bert@qqmail.nl]
>> Sent: zaterdag 28 november 2015 14:32
>> To: stefan.eissing@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 
> 
> 

Mime
View raw message