Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
Date: Mon, 02 Aug 2004 12:59:45 -0700
From: Justin Erenkrantz <justin@erenkrantz.com>
To: dev@httpd.apache.org
Subject: Re: [PATCH] mod_cache fixes: #8
Message-ID: <99867CCF53C1BA317E629B5D@st-augustin.ics.uci.edu>
In-Reply-To: <410E8CB2.3030901@wstoddard.com>
References: <40B25DBF8F84D316162D79F8@[10.0.1.74]>
 <410D0B83.9040100@wstoddard.com> <413520F52887259736D5D43B@[10.0.1.76]>
 <410E378F.1020305@web.turner.com>
 <cc67648e04080206021b2a5662@mail.gmail.com>
 <410E3FEC.1050609@web.turner.com> <568E8683FD2603706426BF68@[10.0.1.77]>
 <410E8CB2.3030901@wstoddard.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

--On Monday, August 2, 2004 2:49 PM -0400 Bill Stoddard 
<bill@wstoddard.com> wrote:

> To get mod_cache/mod_mem_cache (I know little or nothing about
> mod_disk_cache) really performing competatively against best-of-breed
> caches will require bypassing output filters (and prebuilding headers)
> and possibly bypassing or at least reworking input filters. And the

*nod*  However, due to the filter design, it should be easy to move it 
around.  The catch with bypassing the protocol filters is that we have to 
be really smart about the Vary headers and such.

> prebuilt headers will need to be properly aligned in memory. You remember
> the patch I posted to the list, gee, maybe up to 2 years ago now to
> reimplement some aspects of how data was read into input filters? Dipping
> into the input stream to read one line at a time turns out to be a fairly
> significant bottleneck serving cached content. That patch improved
> performance servibg cached content by 5 maybe 10% if I recall correctly.

Is that just for proxies?  Not sure that reading input would be such a 
bottleneck here.  So far, I haven't seen anything to indicate it is.

> I also seem to recall mod_cache/mod_mem_cache making a couple of
> gratuitous calls to apr_time() which can be rather expensive on some
> platforms.  Maybe that has changed since last time i looked at it.

The only similar thing I saw was the ap_set_last_modified().  The explode 
code path had to call down to gmtime which was ridiculously expensive. 
(About 1-2% of the overall time was down in gmtime.)  -- justin