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