On Mon, Sep 27, 2004 at 09:19:12PM +0100, Matt Clark wrote:
> >Basically you set a default in seconds for the HTML results to be
> >cached, and then have triggers set that force the cache to regenerate
> >(whenever CRUD happens to the content, for example).
> >
> >Can't speak for Perl/Python/Ruby/.Net/Java, but Cache_Lite sure made a
> >believer out of me!
> >
> >
> >
> Nice to have it in a library, but if you want to be that simplistic then
> it's easy in any language. What if a process on server B modifies a n
> important value that server A has cached though? Coherency (albeit that
> the client may choose to not use it) is a must for a general solution.
memcached is one solution designed for that situation. Easy to use
from most languages. Works. Lets you use memory on systems where you
have it, rather than using up valuable database server RAM that's
better spent caching disk sectors.
Any competently written application where caching results would be a
suitable performance boost can already implement application or
middleware caching fairly easily, and increase performance much more
than putting result caching into the database would.
I don't see caching results in the database as much of a win for most
well written applications. Toy benchmarks, sure, but for real apps it
seems it would add a lot of complexity, and violate the whole point of
using an ACID database.
(Caching parse trees or query plans, though? It'd be interesting to
model what effect that'd have.)
Cheers,
Steve