Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
Received-SPF: pass (athena.apache.org: domain of dirkx@webweaving.org
 designates 209.132.96.45 as permitted sender)
Message-Id: <CE0EC143-02B6-47D2-948A-251443A8D7D5@webweaving.org>
From: Dirk-Willem van Gulik <dirkx@webweaving.org>
To: dev@httpd.apache.org
In-Reply-To: <DB4D4BCF-8355-4572-B106-1F9B961ADC70@Clickstream.com>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v919.2)
Subject: Re: mod_disk_cache and atimes
Date: Wed, 26 Mar 2008 16:22:56 +0100
References: <C40EC4E9.AB502%Brian.Akins@turner.com>
 <D912CD13-283E-41BF-A23A-C3CBBFFA7CFE@webweaving.org>
 <DB4D4BCF-8355-4572-B106-1F9B961ADC70@Clickstream.com>


On Mar 26, 2008, at 4:15 PM, Konstantin Chuguev wrote:

> Can you please clarify your mentioning the bucket-brigade footprint?  
> Are they so slow they make memory-based cache no more efficient then  
> disk-based one? Or the opposite: sendfile() works so well that  
> serving content from memory is not any faster?
>
No - they are very fast (in an absolute sense) - and your approach is  
almost certainly the right one.

However all-in-all there is a lot of logic surrounding them; and if  
you are trying to squeeze out the very last drop (e.g. the 1x1 gif  
example) - you run into all sorts of artificial limits, specifically  
on linux and 2x2 core machines; as the memory which needs to be  
accessed is just a little more scattered than one would prefer and all  
sort of competition around the IRQ handling in the kernel and so on.

Or in other words - in a pure static case where you are serving very  
small files which rarely if ever change, have no variance to any  
inbound headers, etc - things are not ideal.

But that is a small price to pay - i.e. apache is more of a swiss army  
knife; which saw's OK, but a proper hacksaw is 'better'.

> I'm developing an Apache output filter for highly loaded servers and  
> proxies that juggles small-size buckets and brigades extensively.  
> I'm not at the stage yet where I can do performance tests but if I  
> knew this would definitely impact performance, I would perhaps  
> switch to fixed-size buffers straight away...


I'd bet you are on the right track. However there is -one- small  
concern; sometimes if you have looooots of buckets and very chunked  
output - then one gets lots and lots of 1-5 byte chunks; each prefixed  
by the length byte. And this can get really inefficient.

Perhaps we need a de-bucketer to 'dechunk' when outputting chunked.

Dw