Patrick May wrote:
Hello,
I'm working on a PHP cache library, and I wanted to check in and see
what folks thought.
Usually, you have many different front end views that you will want to
cache. These may pull from multiple datasources in odd ways. Far
away from the front end, there is backend CMS, either a tool like
Wordpress or Drupal, or a custom tool. Generally, I find myself
managing caches by:
1. Putting the code that generates the cache into the front end, since
it is the design that dictates which pieces of information should be
grouped together.
2. Putting a very small amount of code in the back end which causes
the cache to be deleted on the appropriate CRUD operations. CMS's are
complicated enough as they are, and I don't want to clutter them up
more then necessary.
The hard part is creating the association between the front and back
end. What I want to do is to use *tags* to create this association,
and to break caches.
Part of this has to do with your system. For example, Joomla is made up
of Templates, Components, Modules, and Plugins all of which go into
generating a page.
A component will generate HTML content for the main section of the
website(think displaying articles, displaying a directory, etc).
A Module will generate a small block of HTML for specific purposes(think
"most popular articles" list, "advertising banners", "number of users
online")
A template is used to put all of that together into the layout of the page.
Finally, a plugin will take that page and do a bunch of regular
expression find and replaces(so in your content, if you put {contact
author} the author of an articles contact information is placed on the
page).
Therefore, Joomla has multiple levels of caching. As I recall, you can
have it cache the output of specific modules and you can have it cache
the complete page output.
Now, compare that to the Smarty template system. In Smarty, you can
cache the results of applying a template to generate HTML. Smarty also
has an invalidate function, so whenever something is changed you can run
the invalidate function and kill the cached object.
My feeling is it really needs to be taken to the next level. So, when a
cached object is generated, that object needs to record somewhere what
underlying data points make up the cache.
So, for example, your looking at a listing of all articles relating to
PHP and Caching.
As a first step, if an article is added, most systems just do a generic
"invalidate all article cache files" - but a more specific function
would say "lookup all files related to caching that where cached tagged
with X and invalidate them".
A smarter step would be to refresh the cache if possible. So instead of
deleting the existing cached files, generate new ones. Considering that
create/update operations are already expected to be slow, making them a
few milliseconds slower is not a big deal. Especially since the editor
is a user you don't need to worry about getting upset at site slowness
and moving on to a competitors site. Wheras the reader is the person
who you have to be quick for.
However, I will say the main issue is that developers have to USE the
cache. It does no good to have a method of storing data in a cache
unless the developers of the components trigger the flush/refresh
mechanisms that are already there and most CMS systems have(similiar to
the logging facility. It seems every framework has one, yet how often
do people actually add a bunch of extra code to log information except
for failures).
_______________________________________________
New York PHP Community Talk Mailing List
http://lists.nyphp.org/mailman/listinfo/talk
NYPHPCon 2006 Presentations Online
http://www.nyphpcon.com
Show Your Participation in New York PHP
http://www.nyphp.org/show_participation.php
