Mailing-List: contact dev-help@apr.apache.org; run by ezmlm
Precedence: bulk
Date: Tue, 27 Nov 2001 19:02:11 -0800 (PST)
From: Doug MacEachern <dougm@covalent.net>
To: "William A. Rowe, Jr." <wrowe@covalent.net>
cc: dev@apr.apache.org
Subject: Re: apr_buckets_file.c:file_read + XTHREAD
In-Reply-To: <031a01c177b5$0182a690$93c0b0d0@v505>
Message-ID: <Pine.LNX.4.21.0111271857470.8497-100000@localhost>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

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 <dougm@covalent.net>
To: dev@httpd.apache.org
Subject: Re: [patch] major ssl problem
Message-ID: <Pine.LNX.4.21.0111252233510.26287-100000@localhost>

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?