FuzzyRecord documentation

Caching

FuzzyRecord can optionally use caching to improve performance.

What is stored in the caches

FuzzyRecord caches instances of models, in the following ways:

• When you save an object for the first time (eg when write_new() is called), the object is added to the cache
• When you update an object (eg when write() is called), the object will be added to the cache if it doesn't already exist, or the copy in the cache will be overwritten if it does.
• When you delete an object (eg: when delete() is called), the object will be removed from the cache.
• When you instantiate an existing object (eg: $user = new User(123)):
  • If the object exists in the cache, it will set the copy the cached object's properties to your new instance. When this happens, FuzzyRecord won't talk to the database at all.
  • If the object doesn't exist in the cache, it will fetch it's data from the database, and then store it in the cache for later use

What is not stored in the caches

Everything else. :) SQL query results are not cached by FuzzyRecord. All find_all and count queries will run as SQL queries on the database, though matched objects may be pulled from the cache once the search query has run.

How is the data cached

FuzzyRecord can cache data in two ways: the in-memory store, and the Memcached store.

Using the in-memory cache

The in-memory cache stores data only for the duration of a request. It will cache an object the first time it is requested, and reuse the cached object when needed again. Once the request completes, the cache is destroyed, and subsequent requests will need to go to the database again to recreate the object.

The in-memory store will normally only be useful when you want to re-use the same object over and over again, without worrying about managing a reference to it yourself.

Using the memcache store

The Memcached caching server may be used as a more persistent cache. When objects are added to a Memcached cache, they can be reused as part of the same request, and subsequent requests, until their stay in the cache times out, or the cache becomes full and the space they are using is needed for other objects.

Because Memcached is a client server system, a single Memcached store can be used by multiple front-end servers, and caches can be clustered together. For more information on Memcached, see here.

When to use caching

Caching is generally only useful if your website spends a lot of time fetching data from the database. It can massively boost performance for certain kinds of sites (generally those that need to fetch the same model data very frequently).

When not to use caching

Don't use the caches if you are going to be updating model records in the database with raw SQL, otherwise you must be ensure you manually clear the updated records from the cache. For example:

Incorrect:

DB::query("update user set validated = 1");
$user = find_all_by_validated(true); //May pull in records from the cache that are out of date

Correct:

$users = User::find_all_validated(true);
foreach ($users as $user) {
	$user->validated = true;
	$user->save(); // Will update the cache
}
$user = find_all_by_validated(true);

Don’t use the Memcache store if multiple users are likely to be updating the same models at the same time - there is a small (but real) chance that the cache will get out of sync with the database.

Don’t use the in-memory cache or the memory cache if the data you are working with must be 100% up to date at all times. In most situations, it is best to have a single, authoriative source of data (eg: your database). Caching should never be used for financial or privileged data.

Selective caching

If you choose to use one or both of the caches, you can disable caching for a particular model by setting its should_cache property to false in the model definition:

class User extends FuzzyRecord {
 
	static protected $table = "user";
	static protected $should_cache = false;
...