Continued from Part 3…

Let’s make two more changes to complete the process. Here’s the new Controller from earlier where we set the tag “entries” on any Actions where blog entries are displayed or listed.

[geshi lang=php]

class EntryController extends Zend_Controller_Action
{

public function init()
{
$this->_helper->cache(array(‘index’), array(‘tag1′,’entries’,'tag3′));
$this->_helper->cache->useCleaner(‘entry’, array(‘process’,'delete’));
}

public function indexAction()
{
// show some entries, page should be cached
}

public function processAction()
{

// store the blog entry by whatever means necessary
}

public function deleteAction()
{
// delete one or more entries
}

}[/geshi]

Based on the tags being used, we can now simplify our previously nightmarish Cleaner to a single line!

[geshi lang=php]

class ZFExt_Cache_Cleaner_Abstract
{

protected $_cache = null;

public function __construct()
{
// Needing the Action Helper here may suggest the need to extract the
// functionality common to Helpers and Cleaners into it's own
// class for sharing
// Being an article, let's skip the obvious refactoring need before this
// becomes another book...
if (Zend_Controller_Action_HelperBroker::hasHelper('cache')) {
$this->_cache = Zend_Controller_Action_HelperBroker::getExistingHelper(‘cache’);
}
$this->_cache = Zend_Controller_Action_HelperBroker::getStaticHelper(‘cache’);
}

}

class EntryCleaner extends ZFExt_Cache_Cleaner_Abstract
{

public function afterProcess()
{
$this->_cache->removeTaggedPageCache(array(‘entries’));
}

public function afterDelete()
{
$this->_cache->removeTaggedPageCache(array(‘entries’));
}

}[/geshi]

I think we’ll stop here for now!

Conclusion

Over the last three (well, four if you count I ran out of space on Part 2 and needed a 2b ;) ) parts of this weekend series I’ve covered page caching with a focus on caching output to static HTML files to offload work from Apache and PHP.

This caching strategy allows the webserver to avoid PHP completely, or alternatively for a frontend nginx/lighty reverse proxy to avoid Apache completely. Either way, it results in a very fast and efficient caching mechanism for entire pages which can be linked to Tags and Cleaners so they are updated only when the data they were originally generated from has changed.

It should be noted that while static HTML caching is one of the fastest possible caching mechanisms, it is not the most flexible. It is best suited to standalone, or small 2-3 unit scaled solutions, where filesystem operations can be unified with a frontend HTTP server. Trying to sync this style of caching across servers is to be avoided. It is also not suitable for highly dynamic pages which continually update or are specific to each visitor. In these cases the more expensive caching methods are often needed, though if the dynamic portions are small enough it might be worth delegating the generation of those dynamic portions to AJAX requests from the statically cached page, so that at least the bulk of any page is cached.

Additionally, once you do reach the point where static caching cannot be used, you should of course examine other caching options across the parts of the application impacted. Remember that you can cache database results, individual template output (even partials), CPU or memory intensive operations, etc.

In closing, I hope this series has offered a few good ideas :) .

Related posts:

  1. Zend Framework Page Caching: Part 3: Tagging For Static File Caches
  2. Zend Framework Page Caching: Part 2: Controller Based Cache Management
  3. Zend Framework Page Caching: Part 1: Building A Better Page Cache
  4. Zend Framework Page Caching: Part 2b: Controller Based Cache Management
  5. An Example Zend Framework Blog Application Tutorial (Revised)