> Am 21.10.2015 um 16:48 schrieb Graham Leggett <minf...@sharp.fm>:
> 
> On 21 Oct 2015, at 4:18 PM, Stefan Eissing <stefan.eiss...@greenbytes.de> 
> wrote:
> [...]
>> 3. The amount of buffered bytes should be more flexible per stream and 
>> redistribute a maximum for 
>>  the whole session depending on load.
>> 4. mod_http2 needs a process wide Resource Allocator for file handles. A 
>> master connection should
>>  borrow n handles at start, increase/decrease the amount based on load, to 
>> give best performance
>> 5. similar optimizations should be possible for other bucket types (mmap? 
>> immortal? heap?)
> 
> Right now this task is handled by the core network filter - it is very likely 
> this problem is already solved, and you don’t need to do anything.
> 
> If the problem still needs solving, then the core filter is the place to do 
> it. What the core filter does is add up the resources taken up by different 
> buckets and if these resources breach limits, blocking writes are done until 
> we’re below the limit again. This provides the flow control we need.

I know that code and it does not help HTTP/2 processing.

> With the async filters this flow control is now made available to every 
> filter in the ap_filter_setaside_brigade() function. When mod_http2 handles 
> async filters you’ll get this flow control for free.

No, it will not. The processing of responses is very different.

Example: there is individual flow control of responses in HTTP/2. Clients do 
small window sizes on images, like 64KB in order to get small images completely 
or only the meta data of large ones. For these large files, the client does not 
send flow-control updates until it has received all other
resources it is interested in. *Then* it tells the server to go ahead and send 
the rest of these images.

This means a file bucket for such images will hang around for an indefinite 
amount of time and a filter cannot say, "Oh, I have n file buckets queued, 
let's block write them first before I accept more." The server cannot do that.

I certainly do not want to reinvent the wheel here and I am very glad about any 
existing solution and getting told how to use them. But please try to 
understand the specific problems before saying "we must have already a solution 
for that, go find it. you will see..."

//Stefan


Reply via email to