my two cents...

I used to work at a newspaper we used a very elaborate 
caching system, it used to function at the at the 
page subcomponent level (i.e. header, footer, left nav, articles 
were all stored separately) AND page level.  The page 
subcomponents were cached together as pages.   This was a good 
system because it allowed for the subcomponents to be updated 
without effecting the pages (by deleting the subcomponent cache
and leaving the page cache), then subcomponents were regenerated
with new contents, and finally the page caches were deleted
and the pages were then regenerated from the cached subcomponents
(which was the same speed as doing SSI's basically).  Anyway, 
a fast system, a bit complex, a bit ridged (if you want 
dynamic stuff in your pages) but solid for a newspaper.

Now on to DB caching... ADODB has support for Database caching,
it basically dumps the database to a file and reloads it 
transparently when you next do the same select on the DB.  
This would work if you coupled it with a publish event... i.e. 
DB changes -> have a script SSH to the web servers and delete 
the cache / or pregenerate the cache on the db server and upload 
it to the webserver as a temp file and then do a mv to the real
cache file... many ways to skin that cat.


Northern.CA ===-- 
Canada's Search Engine

PHP General Mailing List (
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Reply via email to