RE: [Phplib-users] Caching MySQL queries

[nathan r. h. <na...@ds...>]

On Fri, 26 Oct 2001, Brian Popp wrote:

> A database would obviously be the most portable. How about modifying
> page_open and page_close to include a database object (and it's
> corresponding cache) which gets restored/frozen at the start and finish of
> each page. I'm not sure if the additional overhead would offset any
> performance gains from the cache though? I guess it depends on the
> application.
>

Isn't that what the session stuff does now? :)  In theory your Cache class
shouldn't have to be stateful which means it wouldn't need to load at
start, and would be wasteful if you were laoding that extra info on pages
that don't need it.

Files actually would be most portable (and depeding on your FS Caching and
disk speeds possibly fast enough -- certianly less meory / processor
overhead), but a shmem container would be the speediest, db I can't really
see as being useful if you're trying to speed up db queries, again, unless
they're really big queries and at that point you can cache stuff at the
application level.  I'm probably biased though becasue MySQL is so fast nd
I try to make all my quries as amall as possible -- I tend to prefer to do
several small queries instead of one big one

-n

> -----Original Message-----
> From: Donncha O Caoimh [mailto:don...@tr...]
> Sent: Friday, October 26, 2001 10:36 AM
> To: nathan r. hruby
> Cc: Brian Popp; Phplib (E-mail)
> Subject: Re: [Phplib-users] Caching MySQL queries
>
>
> "nathan r. hruby" wrote:
> >
> > On Fri, 26 Oct 2001, Donncha O Caoimh wrote:
> >
> > > That's the simple explanation. I serialize the array and base64_encode
> > > it before caching it and seperate each record by a "\n". When I read it
> > > back I split the cache by "\n" and eval() the correct row. Not the best
> > > way of doing it but it's the most obvious way I thought of and the
> > > quickest to see if it'd work :)
> > >
> >
> > I picked up on this late, so please shoot me if I'm straying or this has
> > been covered.
> >
> > base64 encoding increases the size of stored vaules by a lot which could
> > be part of the problem when working with large result sets.  Unless you
> > need base64 I'd say just to just serialize the mysql result arrays, add
> > whatever delim you nedd and addslash() them then jsut stripslash(),
> > split() and eval()
>
> Did that and it's easier to debug the cache now.. mimencode just makes
> sure that things are def. not 8 bit characters..
>
> >
> > Question is what kind of metadata does the cache have to make sure the
> > data is fresh and to determine a hit (looking back, md5 sums of the
> > original sql query statement.. i see that should work) and where does this
> > cache live?  If it's living in a db, well, then what's the point except to
> > speed up very complex queries.  Now if it's living in a shmem ssegment,
> > well, that's just darn fast..  With something like Zend cache, you may be
> > able to use a file and let *that* cache engine take care of it too, if you
> > don't feel like coding your own shmem functions
>
> I haven't even looked at that yet. All I'm doing is setting an arbitrary
> timeout on every query. The cache gets stored in /tmp at the moment.
> Again, I'm trying to get it to work first before I do anything exotic
> with it. And also allowing for dropping in other caching scripts too.
>
> Donncha.
>
> _______________________________________________
> Phplib-users mailing list
> Php...@li...
> https://lists.sourceforge.net/lists/listinfo/phplib-users
>

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
nathan hruby / digital statement
na...@ds...
http://www.dstatement.com/

Public GPG key can be found at:
http://www.dstatement.com/nathan-gpg-key.txt
ED54 9A5E 132D BD01 9103  EEF3 E1B9 4738 EC90 801B
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-