> 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


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