Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
Content-Type: text/plain;
  charset="iso-8859-1"
From: Ryan Bloom <rbb@covalent.net>
Reply-To: rbb@covalent.net
Organization: Covalent Technologies
To: dev@httpd.apache.org, Doug MacEachern <dougm@covalent.net>
Subject: Re: [patch] major ssl problem
Date: Mon, 26 Nov 2001 06:44:28 -0800
References: <Pine.LNX.4.21.0111252233510.26287-100000@localhost>
In-Reply-To: <Pine.LNX.4.21.0111252233510.26287-100000@localhost>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Message-Id: <20011126144429.96E2046E02@koj.rkbloom.net>

On Sunday 25 November 2001 10:51 pm, Doug MacEachern wrote:
> 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?

But, that will only happen if we are modifying the contents. I think the best we
could probably do is get rid of the seek call, and if we change the read API,
the malloc.

Ryan

______________________________________________________________
Ryan Bloom				rbb@apache.org
Covalent Technologies			rbb@covalent.net
--------------------------------------------------------------