Caching

Zoop 1.2 adds caching support to Zoop. The Caching component using the zcache object is also integrated into the zones to provide integrated caching support everywhere in your application.

Why Use Caching

Caching is probably the single best way to improve the speed of an application. If used properly you could increase the speed of your application many many times. A simple example, we had a script that took about 3 seconds to run. After we wrote caching support into it that same script took about .03 seconds to run. That is not an uncommon increase in speed thanks to caching.

One of the biggest advantages of caching is storing data. Common uses are for things that take a while to render or generate, or for remote things such as an rss feed. Here's why to use caching. Simple math if you have a RSS feed that your site displays that is updated, lets say hourly. Without caching, every single user would request that remote file every time a page was visited. 5 users a second times 60 seconds times 60 minutes, that is 1800 downloads of the exact same file. Throw in caching and the file is only downloaded once. Perhaps you are worried about having the file be out of date for too long a time, then only cache it for 10 minutes. That is still 6 vs 1800.

The best part is that Zoop makes using caching super easy! Lets see how...

The Zcache Object

Zoop uses the zcache object to do all of it's caching. This object is a special object that has functions that can be called statically or as an instantiated object. There are instances when one way is better than the other. Here I will try to demonstrate examples in both ways. General rule would be, use it statically unless you are planning on caching a number of things, and then instantiate the object with the settings for those things.

Storing and Retriving Data and Strings

Zcache handles raw data (like an array, or object) differently than strings, but can cache both. In this section we will provide four examples, data, strings, intantiated, statically. Here we go. These examples will be in sudo code, so it won't be a complete cut and paste solution, because we won't provide the string or data or what $id to assign, but enough is there that you can modify it for your needs pretty easily.

First Scenario: Strings (like an xml or rss document)

Static:

if (!$XML = zcache::getString($id, array('base' => "MyCacheDirectory")))
{
  $XML = // function call to get XML
  zcache::cacheString($id, $XML, 
	array('base' => "MyCacheDirectory", 'lifeTime' => 60*60*24*7)
	);
}
echo($XML);

Instantiated:

$zcache = new zcache(
	array('base'=> "MyCacheDirectory", 'lifeTime' => 60*60*24*7)
	);
if (!$XML = $zcache->getString($id))
{
  $XML = // function call to get XML
  $zcache->cacheString($id, $XML);
}
echo($XML);

Second Scenario: Data

Static:

if (!$array = zcache::getData($id, array('base' => "MyCacheDirectory")))
{
  $array = array("1", "2", "3");
  zcache::cacheData($id, $array, 
	array('base' => "MyCacheDirectory", 'lifeTime' => 60*60*24*7)
	);
}
echo_r($array);

Instantiated:

$zcache = new zcache(
	array('base'=> "MyCacheDirectory", 'lifeTime' => 60*60*24*7)
	);
if (!$array = $zcache->getData($id))
{
  $array = array("1", "2", "3");
  $zcache->cacheData($id, $array);
}
echo($array);

Common Options and Notes

  • 'base' is a directory that exists inside of the app_cache_dir, which is by default app_dir. "/tmp/cache"
  • 'lifeTime' is in seconds
  • 'group' is a way to organize cached items. A group is a way of organizing like data in the same base.

In the same base and group no two items can share the same id, even if on is data and the other a string. base and group are good ways of organizing the cache logically.

Directories are automatically created recursively, so don't worry about making your base /some/really/long/path/ if it helps you organize things.

Caching + SQL: A Powerful Combination

Caching is particularly helpful in speeding up sql based applications. The less times you request the sql server for the same information, the better. The best part is that an application will know when the sql data changes so it can cache items indefinately and then delete the cache after a sql_insert or sql_update. Caching works best on items that change infrequently… for this example we will cache a settings table. Most people rarely change their settings in an application, so this makes it a great example for using caching. I would create a function to get the settings which could be used anywhere, then In a zoop application you would likely have two different functions, a pageEditSettings and a postEditSettings you would want to write the clear cache function in the later. Some more pseudo code here.

function getSettings($id) {
	if (!$settings = zcache::getData($id, array('base' => "Settings"))) {
		$settings = sql_fetch_one("select * from settings where id=$id");
		zcache::cacheData($id, $settings, 
			array('base' => "Settings", 'lifeTime' => 60*60*24*7*365)
		);
	}
	return $settings;
}

After you saved the data you would place the following line in postEditSettings:

zcache::clear($id, array('base' => "Settings"));

clear clears both data and string type cache.

Clearing Cache

There are four functions for clearing cache.

clear : clears or removes one id is a specific base (and group)

zcache::clear($id, $options_array);

clearGroup : clears all cache of a group in a specific base

zcache::clearGroup($group, $options_array);

clearBase : clears all cache in a passed base

zcache::clearBase($base);

clearAllCache : clears all cache in app_cache_dir (recursively)

zcache::clearAllCache();

Zone Integrated Caching

Each zone you create has a built in zcache object $this->zcache. It is already instantiated with the base set to the name of the zone. This aids in organization since all your cached items are seperated by zones.