httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe Jr." <wr...@rowe-clan.net>
Subject Re: Fixing Ranges
Date Thu, 25 Aug 2011 17:11:29 GMT
On 8/25/2011 11:45 AM, Greg Ames wrote:
> On Thu, Aug 25, 2011 at 10:25 AM, Jim Jagielski <jim@jagunet.com <mailto:jim@jagunet.com>>
> wrote:
> 
>     Now that the memory utilz is being fixed, we need to determine
>     what sort of usage we want to allow… I'm guessing that people
>     are ok with http://trac.tools.ietf.org/wg/httpbis/trac/ticket/311
>     as the guiding spec?
> 
> 
> I'm no longer convinced that we *need* to merge/optimize the Range header.  Stefan's
fix
> to the brigade plumbing has converted O(N^2) memory + CPU use into something scalable.

> 
> Think about the effect of this attack on the CPU cache.  My laptop has a Core i7 with
a
> 64kB L1 data cache.  The cache lines are 64 bytes, so I have 1024 of them per core. 
The
> Range header I'm using has ~1300 byterange specifiers.  apr_brigade_partition in this
case
> will fragment the brigade into ~1300 buckets with length 1 plus one or two for the
> remainder of the file.  Each of those has to be read into the L1 cache somewhere as
> apr_bucket_split walks thru the bucket structures.  That fills the cache with junk and
> throws out the useful information, like the request_req, conn_req, the filter structures,
> and most of the stack.  So not only will the apr_brigade_partition calls perform like
a
> dog but the mainline code will suffer too.

For the raw data you are right... but this is insignificant compared to the
CPU and network cost of assembling and transmitting all of the individual
range delimiters/headers.

Mime
View raw message