Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
Received-SPF: neutral (hermes.apache.org: local policy)
Message-ID: <41DFFBF2.10603@apache.org>
Date: Sat, 08 Jan 2005 07:27:46 -0800
From: Rasmus Lerdorf <rasmus@apache.org>
User-Agent: Mozilla Thunderbird 1.0 (Macintosh/20041206)
MIME-Version: 1.0
To: dev@httpd.apache.org
Subject: Re: Dumb APR_BUCKET_BUFF_SIZE question
References: <41DF6163.2040509@apache.org>
 <Pine.GSO.4.58.0501080052490.12547@cobra.cs.Virginia.EDU>
 <41DF7F17.902@apache.org>
 <Pine.GSO.4.58.0501081013040.12547@cobra.cs.Virginia.EDU>
In-Reply-To: <Pine.GSO.4.58.0501081013040.12547@cobra.cs.Virginia.EDU>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Cliff Woolley wrote:
> It might be.  We've considered having it be configurable before.  There
> are just a lot of implications in changing the value; for example, it
> affects the memory footprint of the server, it affects how much data gets
> read in to memory per read() call on a file bucket (which might alter the
> decision of whether read() or mmap() is preferable, for example), it
> affects how well the data fits into memory pages, and it affects how much
> data is buffered in one block for the scenarios you described.  There are
> probably others I'm not thinking of right now, too.  Lots of different
> axes that must be considered when trying to pick an optimal value.  But
> still, if you want to make it configurable, go right ahead.  :)

Right, I saw all the things it affected which was precisely why I 
wondered why it wasn't made configurable.  I can see perhaps protecting 
users from themselves, but other parts of Apache2 doesn't really follow 
that.  The WindowSize config option in mod_deflate would be a very bad 
idea to change away from the default of 15, for example.  Anyway, I will 
go play a bit with the bucket size on 64-bit boxes.

-Rasmus