apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Doug MacEachern <do...@covalent.net>
Subject Re: apr_buckets_file.c:file_read + XTHREAD
Date Wed, 28 Nov 2001 03:02:11 GMT
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

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?

View raw message