Return-Path: Delivered-To: apmail-apr-dev-archive@apr.apache.org Received: (qmail 66444 invoked by uid 500); 28 Nov 2001 03:09:12 -0000 Mailing-List: contact dev-help@apr.apache.org; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Delivered-To: mailing list dev@apr.apache.org Received: (qmail 66433 invoked from network); 28 Nov 2001 03:09:12 -0000 Content-Type: text/plain; charset="iso-8859-1" From: Ryan Bloom Reply-To: rbb@covalent.net Organization: Covalent Technologies To: Doug MacEachern , "William A. Rowe, Jr." Subject: Re: apr_buckets_file.c:file_read + XTHREAD Date: Tue, 27 Nov 2001 19:12:42 -0800 X-Mailer: KMail [version 1.3] Cc: dev@apr.apache.org References: In-Reply-To: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <20011128031243.1279246E02@koj.rkbloom.net> X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N On Tuesday 27 November 2001 07:02 pm, Doug MacEachern wrote: This seems straightforward to me. The bucket read function doesn't make sense in this case, because we know that we are going to read the entire file, and throw all of it away without ever actually using the data once it has been encrypted. In this case, the SSL module should just read from the file directly. It is kind of hokey, but that is because SSL just doesn't fit our filter model. The filters are written to allow for zero-copy, but SSL isn't a zero-copy operation in this case. The SSL filter will get much better performance if it can allocate a buffer once, and just continue to read into that buffer. As long as it is careful how it uses the file buckets, this won't be a problem. Perhaps a better solution would be to just create a read function that accepts a pre-allocated buffer that we must copy into. Then, filters that know they are going to throw the data away would incur the penalty of the copy in lieu of the penalty of the malloc(). With the file bucket, this has the advantage that the read from the disk can be put directly into the pre-allocated buffer, and the copy doesn't actually exist. Ryan > 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 > To: dev@httpd.apache.org > Subject: Re: [patch] major ssl problem > Message-ID: > > 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? -- ______________________________________________________________ Ryan Bloom rbb@apache.org Covalent Technologies rbb@covalent.net --------------------------------------------------------------