httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Justin Erenkrantz <>
Subject Re: RFC: can I make mod_cache per-dir?
Date Wed, 17 Aug 2005 01:29:19 GMT
On Wed, Aug 17, 2005 at 02:20:59AM +0100, Colm MacCarthaigh wrote:
> On Tue, Aug 16, 2005 at 06:02:04PM -0700, Justin Erenkrantz wrote:
> > The quick handler runs well before any knowledge is available about the
> > backend (dir/file).  The only thing you know is the URI path: unsurprisingly,
> > this is all that CacheEnable and CacheDisable can reasonably work with.
> It's not the only thing, we also have the Cache provider itself. 
> If that lookup is quick enough (it certainly would be for say
> mod_mem_cache) that's how you determine if it's cached. 
> From experience with mod_disk_cache, I don't it's hit as all that
> expensive either, I run millions of requests through "CacheEnable disk
> /" per day without problem, but I still have to concede it is going to
> be slower than a few strcmp's.

Oh, so you mean to see if previous requests have cached it?  But, again, that
doesn't show you a 'negative' (non-cacheable) response.

And, we already have to do this - so I'm not sure what you mean here.

> By the time the cache_save_filter is run, the directory walks have
> happened, so deciding cachability there is trivial.

Right.  But, that's not telling us anything about whether its cacheable or

> > The only way to resolve this is to do the directory walks and file resolution;
> > but that is *very* expensive to do per request.  -- justin
> My changes didn't need this at all. 

Oh.  *light bulb*

Let me see if I understand what you are proposing: only exclude saving the
request by redoing the configuration check in cache_save_filter.  We still
have to go through the entire process as if we were to cache the request; but
we'd block it at the last second from actually being saved in the filter.

Yah, I guess that could work.  -- justin

View raw message