httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jim Jagielski <...@jaguNET.com>
Subject Re: Fixing Ranges
Date Thu, 25 Aug 2011 17:50:41 GMT
I agree we don't *need* to, but we should… 

And we do (now)

On Aug 25, 2011, at 12:45 PM, Greg Ames wrote:

> On Thu, Aug 25, 2011 at 10:25 AM, Jim Jagielski <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.
> 
> Greg


Mime
View raw message