Christopher L. Everett wrote:
But I haven't
been able to wrap my skull around knowing when the data in Mysql is
fresher than what is in the cache without doing a major portion of the
work needed to generate that web page to begin with.
There are three ways to handle cache synchronization:

1) Time to Live (TTL). This approach just keeps the data cached for a certain amount of time and ignores possible updates. This is the most popular because it is easy to implement and gives good performance. Cache::Cache and friends work this way.

2) Polling. This involves checking the freshness of the data before serving it from cache. This is only feasible if you have a way to check freshness that is faster than re-generating the data. This is difficult in most situations.

3) Invalidation. This approach involves removing cache entried whenever you update something that would make them out of date. This is only feasible if you have total control over the update mechanism and can calculate all the dependencies quickly.

One more thing.  Perrin Harkins' eToys case study casually mentions a
a means of removing files from the mod_proxy cache directory so that
mod_proxy had to go back to the application servers to get an up to
date copy.  I haven't seen anything in the mod_proxy docs that says
this is possible.  Does something like that exist outside of eToys?
Not in mod_proxy. We added it ourselves. I don't have the code for that anymore, but it's not hard to do if you have a competent C hacker handy. Maybe mod_accel has this feature.

- Perrin



Reply via email to