httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Gonzalo Arana" <gonzalo.ar...@gmail.com>
Subject Re: Possible new cache architecture
Date Wed, 03 May 2006 19:48:20 GMT
Thanks for bringing me to the light.

On 5/3/06, Graham Leggett <minfrin@sharp.fm> wrote:
> Gonzalo Arana wrote:
>
> > Excuse my ignorance in this matter, but about the 'cache sub-key'
> > issue, why not just use a generic cache (with some expiration model
> > -LRU, perhaps-) with a 'smart' comparison function?
>
> So far one of the best suggestions was from the patch posted recently,
> where the headers and body were in the same file, but where the headers
> were given "breathing room" before the cache body, so that the headers
> can be replaced (within reasonable limits).
> What this means is that each key/data entry is now a single file again
> (like in 1.3), which is much easier to clean up atomically.
>
> The problem still remains that an existing cache file's headers must be
> editable, without doing expensive operations like copying, and this

again, I am in the dark: why do cache request headers may need to be
replaced or edited in the same entity?

> editing must be atomic (no use one thread/process trying to serve
> content from the cache and halfway through, another thread tries to
> update the headers). This will require some form of locking, which may
> be too much of a performance drag, thus blowing the back-to-one-file
> idea out the water.

this makes sense, but I still do not understand the origin of the
problem (in-place header replacement).

> Problems with cache expiry though are a real problem that mod_cache
> suffers from now, and need to be fixed.

That's why I suggested a dedicated process/thread for cache
administration, which is not a good idea if too many lookups are
issued to this process on each request received.

Regards,

--
Gonzalo A. Arana

Mime
View raw message