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: buckets and connections (long post)
Date Thu, 22 Oct 2015 15:55:38 GMT

> Am 21.10.2015 um 16:48 schrieb Graham Leggett <minfrin@sharp.fm>:
> 
> On 21 Oct 2015, at 4:18 PM, Stefan Eissing <stefan.eissing@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



Mime
View raw message