[Dbix-class] Dbix-class] Caching (was: Ok, let's begin)

John Siracusa siracusa at mindspring.com
Tue Sep 20 23:08:55 CEST 2005


On 9/20/05, Matt S Trout <dbix-class at trout.me.uk> wrote:
> On Tue, Sep 20, 2005 at 11:45:11PM +0200, Krzysztof Krzyzaniak wrote:
>> Bill Moseley wrote:
>>>On Tue, Sep 20, 2005 at 11:08:32PM +0200, Krzysztof Krzyzaniak wrote:
>> I think this should have advantage when results are cached. When results are
>> not cached it probably doesn't matter. But this demand some tests.
> 
> The advantage of $rs->next is it does the $sth->fetchrow at the time, so
> you aren't pulling data until you need it. The distadvantage is that doing
> it this way is a little less efficient than ->all in terms of DBI and perl
> time.
> 
> There's no caching at all so far; I was thinking about something along the
> lines of the Sweet object cache, but it's not really my area.
> 
> Siracusa? Given you're current maintainer of the speed demon among the perl
> ORMs, do you have any suggestions?

My suggestion is: don't cache at the "core" RDBMS-OO-mapper level at all.
Flexible, generic caching adds significant overhead, and most people won't
use it.  Or rather, they probably shouldn't, since caching at a higher level
(e.g. the Mason component level or even the app level) is more efficient,
and usually more sensible.

For example, a CRUD app probably doesn't want to cache at all...except
perhaps on the "search" screen, which it can cache in its entirety using
cache key based on the query string (or POST data, whatever--basically, app
params).

OTOH, an online store may want to cache "everything" for, say, 1 minute.
(Even 30 seconds may be a worthwhile cache timeout if the site is getting
hundreds of hits per second.)  But again, it makes more sense to cache, say,
the product listing portion of a page (that is, the template that generates
it) using a cache key based on the args to that template, rather than
evaluating the template every time and pushing the caching down to the
RDBMS-OO mapper.

Basically, I think the "big win" is in caching at a high level (app, page,
component) and a low level (the database server itself and the OS below it).
The "middle" part (the RDBMS-OO mapper) can just stay out of it, in most
cases.

That said, if people want caching at the RDBMS-OO level, I'd make them use a
subclass that wraps the "core" functionality and overrides all the
cache-able methods...or however the heck you do it in the wacky world of
DBIx::Class, where you inherit from 50 different things ;)  Basically, keep
all the caching code out of the "normal" code path, and only add it if the
user explicitly requests it.

-John





More information about the Dbix-class mailing list