httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bert Huijben" <>
Subject RE: H2 stream dependencies
Date Fri, 20 Nov 2015 18:37:16 GMT
> -----Original Message-----
> From: Stefan Eissing []
> Sent: vrijdag 20 november 2015 10:26
> To:
> Subject: Re: H2 stream dependencies
> Bert,
> interesting and nice to see the progress. You probably could use priorities for
> ordering, especially when using the stream dependencies. I am not certain,
> however, if this will give you totally deterministic behavior. If stream B
> depends on A, usually A will be sent out before B. However, should stream A
> become suspended - e.g. unable to progress, either because there is no data
> available which some other thread needs to produce, or because the flow
> control window has not been updated in time - the server will start sending
> data for B.
> The state of the implementation is:
> 2.4.17: fully implemented priority handling on sending stream data, as
> implemented by the nghttp2 library
> 2.4.18: additionally, streams are scheduled for execution by priority. Makes a
> difference when the number of available worker is less than the stream
> queue length, e.g. when der server is under load or only few workers are
> available (in prefork, for certain).
> Another way to influence the ordering is for the client to play with the
> stream window sizes. If you give stream A 2^31-1 and stream B 0 until you
> have A, then update B, it may also do what you want. If both streams
> produce response bodies...flow only applies to DATA...

I'm currently thinking about combining both approaches... Sending the dependencies and (just
to be sure) also keep the window low on such a stream. In that case only a very small cache
should be able to handle the delaying in case (somehow) the dependency doesn't do the right

In the specific case of Subversion there shouldn't be many cases where output is delayed,
so I hope this will just work for us. But once we see h2 proxies, I'm guessing we will really
need the window handling as fallback.

In a few of the remaining test failures I see httpd spinning at 100% CPU (automatically cooling
down after some timout; perhaps if the connection is closed). I haven't investigated those,
but it could be an httpd issue. This usually triggers other test failures for me as I limit
the amount of workers and threads while testing. I'll follow-up when I know more.


View raw message