Garth, > my two cents...
=thank you for the description - it is worth more than a figurative 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. =makes sense as an architecture =were the page subcomponents formatted as HTML or simple text? =how was the fact that a particular page used certain subcomponents tracked? (eg to know what to update, when) > 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. =why did/do you think the newspaper made the decision to do the former, than to try this ADODB-type solution? =they both achieve the stated objective (reduce load on the db-server). Is one somewhat lesser/better than the other? =Regards, =dn -- PHP General Mailing List (http://www.php.net/) To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
