Performance

Caching​

This information is relavent as of 09 July 2011


Andrew Eddie has a great [http://www.theartofjoomla.com/joomla-caching-explained.html introductory article to Joomla 1.5's caching Options] Please read that first before continuing here.


Here's how the various caching Options relate to Fabrik

How Fabik uses Joomla's Various Caching Methods​

Caching the entire page will only work if you are showing static table data, and you don't want your users to interact with it via Forms.






this is what we rely on the most. Caching occurs when the Joomla global cache config option is turned on.

Unlike com_content. It is ON regardless of whether the user is logged in or not.


Unline most Joomla cache pages, which create a cache file based on the url, fabrik creates a unique cache file based on the post data, the url and the user id. This allows for the various dynamic aspects of Fabrik to still function whist caching views as often as possible. The downside to this is that you may find Fabrik creating a large number of cache files. (located in /cache/com_fabrik/)





we don't use this. Instead the Modules create a standard component view and use the Joomla global cache config option to determine if their view should be returned from the cache.

Joomla Content Plug-ins​

The fabrik content plugin also makes use of caching. However, please note that as com_content will cache data for users who are not logged in, the dynamic features of fabrik tables are not available (e.g. filtering, navigation and ordering will not work) unless the table's 'Ajax filter/nav' option is turned on. Even with this option turned on the filters are not sticky - so refreshing the page will revert the table back to its initial view.

A case study of Fabrik's caching process​

Fist we've logged into our sites administration page, selected Site > Global Configuration from the top menu and the 'system' section we have turned on the 'Cache' option.

We've already created a Fabrik table and published it on our site with a menu link.

The first time you view this table Fabrik asks Joomla to create a cache file for the table view. The cache file is stored in cache/com_fabrik, with a long serialized name, but for clarity lets refer to this file as a.php.

If you refresh the page Joomla's cache system checks if a.php is there and if so uses that rather than running the Fabrik code to create the table.

When you go to page 2 of that table, the information you want to see is not the same, so we can't use a.php, so Fabrik asks Joomla to creates b.php. Any unique combination of filtering, ordering and navigation will create a unique cache file, as the data to display is also unique.

So now we have two cache files, a.php (for the first page of table data) and b.php (for the second page of table data)

When either of those views is requested their cache file is used, dramatically speeding up page render times.

Now, if user X logs in then what he sees for the table may not be the same (due to prefilters etc) as non-logged in users, so a new cache file c.php is created. When that user views the table again he sees c.php and not a.php.

If he then goes to the table's form and add/edits a record then a.php, b.php and c.php are all deleted (as we don't have any way of knowing which cache file's data might no longer be correct seeing as 'something' has been altered in the database)