httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Graham Leggett" <>
Subject Re: mod_cache responsibilities vs mod_xxx_cache provider responsibilities
Date Mon, 18 Sep 2006 07:50:41 GMT
On Mon, September 18, 2006 9:35 am, Niklas Edmundsson wrote:

> The easiest way to deal with this might be to have a timeout, if the
> body hasn't shown up in $timeout time then something went bad,
> DECLINE, meaning that the cache layer thinks it should cache the file
> and acts accordingly. You actually want this fallback anyway, and it's
> probably enough to deal with the purge-problem. The purge should
> delete the oldest unused entries anyway, so the chance of hitting that
> case shouldn't be too common.

A timeout like this isn't different from a backend that doesn't respond
within a reasonable amount of time - this could be the same timeout.

> And yes, since this scheme only might cause on-disk stray files that
> can be cleaned up by purging I can agree that it'll work. However, I
> strongly believe that the purging should not have to read each header
> file the way that htcacheclean currently does it since it poses such a
> strain on the cache filesystem. A file system traversal should be
> enough.

I have not seen inside the htcacheclean code, why is the code reading the
headers? In theory the cache should be purged based on last access time,
deleted as space is needed.

> Anyhow, I can probably rather easily adapt our patches to do it this
> way if that's what people want. I'm not entirely sure what the gain
> would be though, since it's a tad more housekeeping work and double
> the number of inodes to traverse during a purge...

I would like to investigate Brian's comments that having the body in a
single file is a performance win before a method is chosen.

> But, that is future work. I haven't had any comment of the current
> patch of mine yet (lfs-config) so I'm not entirely sure of whether it
> seems OK and I should proceed with the next patch or what.

Your patch is battle tested, and fixes some specific problems, the only
issue that I think needs to be resolved is the question of whether single
file or multiple files are preferable, taking into account performance on
platforms other that Linux as well.

What would help a lot is to break the patch down into bits that fix
specific issues. The "load the entire file into RAM before delivery" issue
is a definite candicate for solving.


View raw message