Re: [Phpslash-devel] Re: [phpslash-users] Cache problem/bug + request

[Peter C. <li...@kr...>]

At 18:23 06/11/02 +0800, Sam Williams wrote:
>On Wed, 2002-11-06 at 03:35, Aric Caley wrote:
>> From: "Peter Cruickshank" <pe...@kr...>
>> > >The cache_id could be generated by taking the variables we are concerned
>> > >with (for example, the language and skin), serializing them and doing an
>> > >MD5() on that.  Perhaps we'd want to additionaly add another string (one
>> for
>> > >blocks, one for articles, etc) to keep the numbers more unique.  I dont
>> know
>> > >that much about hashing but this would seem to work.
>> > >
>> > >Then each block_render_* function can check if there's something in the
>> > >cache table by generating this ID, and if not, put in an entry.  This
>> does
>> > >add another SQL query, though we will be able to cache things more often
>> > >then before (especialy if you have different skins, languages, etc on
>> your
>> > >site).
>> > >
>> > >Also, we can use the cache table for other things besides blocks.  I dont
>> > >know if there's much to be gained by caching articles on phpslash, but I
>> can
>> > >certainly use this in my shopping cart project.
>> >
>> > It would be really good if it was possible to come up with a caching API
>> which was neutral between file and database-based caching. Not that it's
>> strictly relevant for PSL, but the BE code also caches stuff that's not held
>> in the block tables. It would be great if BE and PSL could share caching
>> methods
>
>Not sure what everyone else thinks, but in my opinion it would be nice
>to give the caching system for phpslash a complete overhaul... a file/db
>neutral caching API sounds like a winner.
>
>For me, the most important thing to cache would be the complete home
>page that new visitors arrive at (with the default skin). I find almost
>all my users use this as a jumping point for the rest of the site (very
>few seem to bookmark deeper links) and generating it every time seems
>like a huge waste of resources. Is there anyone else here who would
>prefer it to be stored as a flat html file that is rebuilt every X min? 

This sounds like something that jpcache does. 

I suppose we might be talking about two different things, or issues that can be solved in two different ways:
* page-level caching for non-personalised parts of the site, where techniques such as 303(?) No Change headers can be used
* block-level caching elsewhere (here 'block-level' could include the output of slashHead and slashFoot as well). Customised pages are built out of cached elements.

At first thought, there only need to be three methods in the API for block-lvel caching:
      CONSTRUCTOR($identifier, ?plus $subcat) - build up the private handle for the cached data using MD5 and other tricks. Not sure exactly what the identifier would look like...
      mixed fetch()  - returns the data if there's a valid cache still in existence, else 'false' signalling that you need to (re)build the block
      void store(mixed $content, integer $lifetime='') - saves the updated block (serialising $content), giving it the default lifetime unless otherwise specified
This is the approach I took on the one project I've taken part in where caching was needed - I built a wrapper around Manuel Lemos's filecache.class (http://www.phpclasses.org/browse.html/package/313.html) mostly because I wasnt going to use the more fancy features in jpcache. It'S Got the advantage of keeping the specifics of how the data is named in the caching system away from the higher-level logic.

There might well be / probably are better ways of solving the problem though...

>> That should be easy enough.  Seems like file caching would be slower than
>> using the DB, but I guess if your server is set up right it can be caching
>> the files which could result in being faster than the DB.
>
>Please correct me if I am wrong, but I thought accessing the file system
>to retrieve a file was quicker than querying the database server(s)
>across the network?

I've seen arguments go both ways on this one, so it must be configuration dependent. Anyway, that's why I suggested a file/db neutral API so we dont have to have this debate!

>> Is my idea (well, more than idea now as I've already implemented it :) for
>> using MD5 to generate ID's a good one?

FWIW, I think so - especially if you stick a block-id on the front of the ID which will reduce the chances of a clash even more (and make the results of a clash look less bad)

Peter