in reply to To cache or not to cache

This isn't directly related to the OP's question, but it sparked my curiousity:

When I ask for info about the user (say $user->get('zipcode')) I first check if the data is currently defined in the instance. If not, I check the session cache (currently Cache::Filecache) and finally, if it hasn't been found, I query the DB.

How much overhead do you (OP and others reading this) think this adds per request? I guess the value would be highly dependent on how frequently the request makes it to the DB request phase.

I wonder if maybe a persistent DBI connection might provide more overall value than locally caching the data.

---
It's all fine and dandy until someone has to look at the code.

Replies are listed 'Best First'.
Re^2: To cache or not to cache
by blogical (Pilgrim) on Mar 13, 2006 at 18:12 UTC
    Hopefully it reduces the overhead over the course of a session. It seems better than pre-loading everything that might be needed into the instance for every request, or calling the DB for each piece individually as it is requested over the course of the session.
    • Look as close to home as possible first (memory->cache->DB)
    • Trade a little memory/storage space for the length of the request/session to cut down on DB calls.
    • Try to avoid DB calls by retrieving relevant info on the first call.
    • Reusable data migrates into the cache, and lives there until the session ends- hopefully quicker and lower cost than DB calls.

    I'm using a persistant dbhandle (or it WILL persist when I get this onto mod_perl). But calling also requires figuring out where to get the data from, forming the request, dealing with the call...