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.