3

Can someone explain the difference between this two frontends Zend_Cache_Frontend_Capture and Zend_Cache_Frontend_Page?

the Capture is the default one for page caching ... the weird thing is, it makes the id with get variables, but there is no options to set make_id_with_get_variables like its the case in Page frontend....

can someone explain this ?

StPiere
  • 4,113
  • 15
  • 24

1 Answers1

3

Here is my effort to explain the differences between the two.

To start out, let's look at Zend_Cache_Frontend_Capture. The reference states that this class is designed to work only with Zend_Cache_Backend_Static.

You would use Zend_Cache_Frontend_Capture to cache entire pages that have no relation to the user accessing the site. You use this frontend when you have static data (that could change from time to time) that has no relation to the current user, that is, it is the same for all users (like an RSS feed or dynamically created JavaScript file for example.

Looking further into the Zend_Cache_Backend_Static, you will see that this backend is a bit special. It requires rules in your .htaccess file to assist with serving the cache. Once you have cached something with Frontend_Capture/Backend_Static, PHP and Zend Framework are NOT used in order to serve the cached data. Apache sees that the cache file exists based on your .htaccess and serves the content directly to the user without invoking PHP.

Zend_Cache_Frontend_Page on the otherhand works differently. With it, you can cache content not only based on the request URI, but also based on information in a cookie, session, GET, or POST parameters. By default, caching based on cookie, session, get, and post is disabled, so for this to have any effect on a user logged into your site, you have to tell the cache if there are any pages you want to cache based on that information.

Once I create a cache and tell it I want to cache based on cookie and session, I can now cache a dynamically generated page that is specific to one user. So if person A accesses /accounts/, the page can be cached for that specific user containing the list of their accounts that was pulled from the database. Now when person B accesses /accounts/, they do not see the cache for person A, so the page is now cached separately for them with each respective user's information in their own cache.

In summation:

  • Use the Capture frontend when you have data you can cache that is the same for ALL users. This will be a higher performance cache since PHP and ZF is not needed once the page is cached. The downside is having to add caching rules to .htaccess

  • Use the Page frontend if you want to cache pages with dynamic output based not only on request URI, but the cookies, session data, or get/post parameters.

Hope that is clear and helps you understand the differences.

EDIT: I believe I see what the problem is, not sure if this is classified as a bug or not though.

Zend_Controller_Action_Helper_Cache::preDispatch() generates the cache ID based on the request URI (which includes the query string). Since the jQuery ticker appends a query string to the URL, you are caching one copy of the feed for each request URI. (Look for $reqUri in the aforementioned class method).

I see a couple of options: 1) See if you can get the ticker to not append the query string (at least for that specific URL) or 2) Manually start the Capture cache and pass your own ID, rather than letting the cache helper generated it based on the request URI.

drew010
  • 68,777
  • 11
  • 134
  • 162
  • Thank you, drew! That was very clear explanation .... But is it that case normal that the Capture Frontend caches the get variables? in my case i have an RSS feed, which i want to cache staticaly, and im using jquery.ticker plugin to get this feed via ajax... now, this plugin sends an unique get parameter like _=1338373213 and the cached page is then feed?_=1338353213 ... i think the capture cache should not consider the get, post, cookie variables, but it seems like it does ... or am i doing something wrong here? im calling the cache from Action_Helper_Cache – StPiere Feb 11 '12 at 20:57
  • It doesn't appear that it should base the cache off of request URI, but I think the Helper Cache may be causing this to happen. Can you post some code to pastebin showing any bootstrap config of the cache, and how you use it in the controller for me? – drew010 Feb 11 '12 at 21:38
  • Hi,drew! thanks for fast reply ... here is the bootstrap cache configuration [link](http://pastebin.com/YNrK6K8g) – StPiere Feb 12 '12 at 15:03
  • Do you call `$cache->start('name', $tags)` anywhere in your controller to tell it you want to cache, or maybe I'm just missing something with the cache manager itself. – drew010 Feb 13 '12 at 03:54
  • Sorry I completely missed that line, almost did the second time as well! I think I see what the problem is, see the EDIT I made to my answer a few moments ago. It looks as if the cache helper IS using the request URI (query string included) to generate the cache ID. – drew010 Feb 13 '12 at 23:01