apr-dev mailing list archives

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


> 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?


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

View raw message