By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
455,446 Members | 1,556 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 455,446 IT Pros & Developers. It's quick & easy.

Content management and caching

P: n/a
Hi

I use PEAR Cache to cache the frontend pages of a content managed web site.
Now I update the contents of a page, and of course the updated contents will
only be displayed after the expiring period of the cached file.

After thinking and googling a lot I see several possible approaches to for
handling this, each of which has it's downsides:

- Use a very short expiring period. (Downside: Makes caching only relevant
at very high visitor frequencies.)

- Change database, add modification date to every record - and compare
creation date of cache files with modification dates of contents. (Huge
overhead; must first detect which tables and records the page uses at all.)

- Flush cache everytime an admin page is called, or within the insert,
update, publish etc functions. (Empties whole cache also if only a comma is
changed.)

- Provide an "flush cache" button for the administrator to use after
finishing changes. (Administrator will forget it.)

I would appreciate any better ideas or comments, thank you.

--
Markus
Jul 17 '05 #1
Share this Question
Share on Google+
9 Replies


P: n/a
Hello,

On 10/14/2004 02:20 PM, Markus Ernst wrote:
I use PEAR Cache to cache the frontend pages of a content managed web site.
Now I update the contents of a page, and of course the updated contents will
only be displayed after the expiring period of the cached file.

After thinking and googling a lot I see several possible approaches to for
handling this, each of which has it's downsides:

- Use a very short expiring period. (Downside: Makes caching only relevant
at very high visitor frequencies.)

- Change database, add modification date to every record - and compare
creation date of cache files with modification dates of contents. (Huge
overhead; must first detect which tables and records the page uses at all.)

- Flush cache everytime an admin page is called, or within the insert,
update, publish etc functions. (Empties whole cache also if only a comma is
changed.)

- Provide an "flush cache" button for the administrator to use after
finishing changes. (Administrator will forget it.)

I would appreciate any better ideas or comments, thank you.


You may want to try this other generic cache class that stores arbitrary
cache data in files. It comes with a function that lets you invalidate a
specific cache file forcing the content to be regenerated next time the
cache is used.

I use this precisely for the same reasons as your in a site where over
10.000 content blocks are cache in files taking over 150MB . Some of the
cache files expire after a certain amount of time but in some cases I
need to force certain cache files to be regenerated due to some event
that could not be antecipated when it would happen.

This solution works wonders not only for that purpose but also because
it uses safe locking which is very important to prevent cache corruption
in a busy site like I have when many simultaneous user accesses attempt
to verify and update the same cache files.

http://www.phpclasses.org/filecache
--

Regards,
Manuel Lemos

PHP Classes - Free ready to use OOP components written in PHP
http://www.phpclasses.org/

PHP Reviews - Reviews of PHP books and other products
http://www.phpclasses.org/reviews/

Metastorage - Data object relational mapping layer generator
http://www.meta-language.net/metastorage.html
Jul 17 '05 #2

P: n/a
Markus Ernst wrote:
I use PEAR Cache to cache the frontend pages of a content managed web site.
Now I update the contents of a page, and of course the updated contents will
only be displayed after the expiring period of the cached file.

After thinking and googling a lot I see several possible approaches to for
handling this, each of which has it's downsides:

- Use a very short expiring period. (Downside: Makes caching only relevant
at very high visitor frequencies.)

- Change database, add modification date to every record - and compare
creation date of cache files with modification dates of contents. (Huge
overhead; must first detect which tables and records the page uses at all.)

- Flush cache everytime an admin page is called, or within the insert,
update, publish etc functions. (Empties whole cache also if only a comma is
changed.)

- Provide an "flush cache" button for the administrator to use after
finishing changes. (Administrator will forget it.)

I would appreciate any better ideas or comments, thank you.


Turck MMCache (http://turck-mmcache.sourceforge.net/) - haven't done a
lot with it yet, but it seems to be reducing overhead a bunch on my CMS,
and I haven't noticed out-of-date content being served...

--
Justin Koivisto - sp**@koivi.com
http://www.koivi.com
Jul 17 '05 #3

P: n/a
Justin Koivisto wrote:
Turck MMCache (http://turck-mmcache.sourceforge.net/) - haven't done a
lot with it yet, but it seems to be reducing overhead a bunch on my
CMS, and I haven't noticed out-of-date content being served...


That looks nice, thank you, but I am on shared hosting, so I can't change my
server configuration.

--
Markus
Jul 17 '05 #4

P: n/a
Markus Ernst wrote:
Justin Koivisto wrote:

Turck MMCache (http://turck-mmcache.sourceforge.net/) - haven't done a
lot with it yet, but it seems to be reducing overhead a bunch on my
CMS, and I haven't noticed out-of-date content being served...

That looks nice, thank you, but I am on shared hosting, so I can't change my
server configuration.


I know the feeling... I will be convincing an ISP or two in the area to
support it. The install only takes like 5-10 minutes on the server side.

--
Justin Koivisto - sp**@koivi.com
http://www.koivi.com
Jul 17 '05 #5

P: n/a
Hi Markus,

Markus Ernst wrote:
- Change database, add modification date to every record - and compare
creation date of cache files with modification dates of contents. (Huge
overhead; must first detect which tables and records the page uses at all.)


Not necessarily. One could do what in A.I. is called 'truth maintenance'
on the database: If you pass all queries that are executed through a
single funcion, the funcion can pass them to a parser and the parse tree
to a cache maintenance function, records can be created that relate the
elements of each select statement to the page. Then when an update or
insert statement comes across, the parse tree from the update can be
used to search those records for query elements whose funcion might be
affected by the update, insert or delete. If properly combined into
logical conditions the affected pages can be identified quite efficiently.
For example an update the record in the 'menu' table with 'id' = 12,
might require a query for pages that perform a select on the 'menu'
table with conditions that inlcude 'id' and are true for id = 12.

Of course the parsing of queries if a page is not in the cache, and
querying for affected pages only on inserts, updates and deletes. Cache
performance itself will not be affected.

I admit programming this is complex, but once it is done it will be
simple to reuse the program to get a list of the urls of the pages that
need to be flushed from the cache. Or maybe it could be in the database
itself: simply pass the database the url of your page with each select
statement and it will be able to give you all affected urls after each
transaction. I guess it should not be hard to find a univeristy
informatics student that wants to work this out into a working
prototype, if that has not already been done. I wonder if oracle, ibm or
so is already working on this.

Greetings,

Henk Verhoeven,
www.phpPeanuts.org.

Jul 17 '05 #6

P: n/a
Justin Koivisto <sp**@koivi.com> wrote in message news:<Lp*****************@news7.onvoy.net>...
<snip>
Turck MMCache (http://turck-mmcache.sourceforge.net/) - haven't done a
lot with it yet, but it seems to be reducing overhead a bunch on my CMS,
and I haven't noticed out-of-date content being served...


Sorry, but may I know your PHP version? This confirms issues in
production servers <http://sourceforge.net/tracker/?group_id=69426&atid=524487>

--
| Just another PHP saint |
Email: rrjanbiah-at-Y!com
Jul 17 '05 #7

P: n/a
R. Rajesh Jeba Anbiah wrote:
Justin Koivisto <sp**@koivi.com> wrote in message news:<Lp*****************@news7.onvoy.net>...
<snip>
Turck MMCache (http://turck-mmcache.sourceforge.net/) - haven't done a
lot with it yet, but it seems to be reducing overhead a bunch on my CMS,
and I haven't noticed out-of-date content being served...

Sorry, but may I know your PHP version? This confirms issues in
production servers <http://sourceforge.net/tracker/?group_id=69426&atid=524487>


4.3.8

--
Justin Koivisto - sp**@koivi.com
http://www.koivi.com
Jul 17 '05 #8

P: n/a
Justin Koivisto <sp**@koivi.com> wrote in message news:<XW*************@news7.onvoy.net>...
<snip>
Sorry, but may I know your PHP version? This confirms issues in
production servers <http://sourceforge.net/tracker/?group_id=69426&atid=524487>


4.3.8


Thanks:)

--
| Just another PHP saint |
Email: rrjanbiah-at-Y!com
Jul 17 '05 #9

P: n/a
R. Rajesh Jeba Anbiah wrote:
Justin Koivisto <sp**@koivi.com> wrote in message news:<XW*************@news7.onvoy.net>...
<snip>
Sorry, but may I know your PHP version? This confirms issues in
production servers <http://sourceforge.net/tracker/?group_id=69426&atid=524487>


4.3.8


Thanks:)


Something that I'm not seeing there?

--
Justin Koivisto - sp**@koivi.com
http://www.koivi.com
Jul 17 '05 #10

This discussion thread is closed

Replies have been disabled for this discussion.