On 8/25/2011 11:45 AM, Greg Ames wrote: > On Thu, Aug 25, 2011 at 10:25 AM, Jim Jagielski <j...@jagunet.com > <mailto:j...@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.
