Zend Framework – Page Caching

Well along the Zend Framework journey, the biggest issue now is performance, since the applications run on shared hosting accounts. We have caching enabled for the navigation menus, translation, and even Doctrine queries, however the pages still load slow.

Well one of the caching front ends (http://framework.zend.com/manual/en/zend.cache.frontends.html) is the Page front end. The configuration is the same as the other front ends sharing all the properties of the Core front end. While this speeds up the page loading significantly, it is difficult to use with dynamic pages such as lists, since new values are not added until the cache expires.

One way out of this issue is to tag the page caches with the controller name and expire all the pages served by a controller when new data is processed by the controller. This required a bit more digging around, but the following steps worked for us:

  1. Setup the Page cache configuration in the application.ini – remember to disable the Front Controller output buffering
  2. Initialize the page cache in the application bootstrap and store it in the registry, using the Zend_Registry singleton
  3. In the base controller (we setup one where common initialization is done):
  • Add a function to clean the cache for tags that match the controller name
  • Initialize the page cache and start it in an init method, but remember to add the tag with the controller name, using a line similar to $pageCache->setOption(‘tags’, array($this->getRequest()->getControllerName()));
  • Call the function to clear the controller cache in any method that modifies the database information

This seems to work for now, and we are looking for ways to improve its performance.

PS: Special thanks go to @weierophinney for pointing me in the right direction as I pulled hair out of my head.

Update: From August 2011, we stopped using the page caching due to issues we had with session and cookie variables not working. Also an upgrade to Zend Framework 1.11 fixed most of the performance problems which had necessitated us to have page caching in the first place.

Basically we wanted to have a cache for each page for each user which we failed to achieve in testing scenarios.

Advertisements

One response to this post.

  1. Posted by HM on June 19, 2011 at 11:45 am

    indeed thx to @weierophinney for saving you on barber costs

    Like

    Reply

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: