On Tue, 27 Nov 2001, William A. Rowe, Jr. wrote: > If that's true, we have some serious work to do. Do you have a good sense > for how much overhead we are talking about here [bucketwise?]
see message below. i said 'putting ssl aside', but this actually only happens in the case of a filter such as ssl where we modify the contents of a file. you can add to the list ~1200 calls each: - to file_make_mmap() function (which always fail) - malloc sizeof(apr_bucket) Date: Sun, 25 Nov 2001 22:51:39 -0800 (PST) From: Doug MacEachern <[EMAIL PROTECTED]> To: [email protected] Subject: Re: [patch] major ssl problem Message-ID: <[EMAIL PROTECTED]> On Sat, 24 Nov 2001, Cliff Woolley wrote: > Actually, that's not exactly true. If APR_HAS_MMAP, and the file bucket > is between MMAP_THRESHOLD and MMAP_LIMIT (MMAP_LIMIT is 4MB by default), > then yes, len will be up to 4MB. But if the file bucket is bigger than > 4MB or the system doesn't have MMAP, then len will *never* be bigger than > APR_BUCKET_BUFF_SIZE (8KB). hmm..putting ssl aside, lets say we have a 10Mb file, looking at apr_buckets_file.c:file_read() that's ~1200 calls each to: - malloc for the 8k buffer - seek() for the current offset - read() of 8k for the actual buffer not to mention the APR_BRIGADE_FOREACH loop and whatever else is in between. seems that could use some performance tuning of its own?
