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 <[email protected]> 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
