Working with Data Cache

This feature provides options to determine where to store cached variables. Memory caching improves server responsiveness and increases performance - primarily in environments that run high-traffic applications that can benefit from off loading activity directed toward their hard disk. Disk caching is more suitable for smaller applications and ensures the cached content is available after the machine is restarted.

SHM/disk storage is implemented by using the appropriate API functions and configuring the Data Cache directives.

Note:

Memory option error messages have been created to notify you if the store operation fails or you run out of allocated memory.

The following example shows the different storage options:

// A simple key with no namespace stored on disk:
if (zend_disk_cache_store("hello1", 1) === false){
	echo "error2\n"; 
	exit();
}
// Shared memory:
if (zend_shm_cache_store("hello1", 1) === false){
	echo "error2\n"; 
	exit();
}
// Store with namespace on disk:
if (zend_disk_cache_store("ns1::hello1", 1) === false){
	echo "error2\n"; 
	exit();
}
// Shared memory:
if (zend_shm_cache_store("ns1::hello1", 1) === false){
	echo "error2\n"; 
	exit();
}
 
// Store with namespace on disk with limited lifetime:
if (zend_disk_cache_store("ns3::test_ttl", 2, 3) === false){
	echo "error12\n"; 
	exit();
}
// Shared memory:
if (zend_shm_cache_store("ns3::test_ttl", 2, 3) === false){
	echo "error12\n"; 
	exit();
}
 

Using namespaces for caching provides the ability to define a key that can serve as an identifier to delete select items from the cache, rather than unnecessarily removing shared instances. 'namespace' support is intended for environments that run large applications that are separated into modules. Applying a 'namespace' to each module provides the identification necessary to pinpoint all the cached items that belong to a given module and remove only those specific items.

This does not mean that you must use the 'namespaces' to clear the cache: The entire cache can be cleared by using the 'output_cache_remove' function.

Setting the cached 'namespace':

The cache 'namespace' is set by adding it as a prefix to the cache with '::' as the separator.

Defining the Cache folder depth is intended for environments that use a large number of keys. By definition, cached content is separated into different directories by key, to prevent performance degradation caused by accessing files that contain large amounts of content. This option is only available with disk caching. Increase the cache folder depth according to the quantity of content that requires caching (small amount = 0, large quantities = 2).

Note:

A single directory may include several keys, depending on the quantity of cached content.

The cache folder depth is defined by the directive zend_cache.disk.dir_levels. The value of the directive configures how the cached files are stored. The accepted values for this directive are 0, 1 or 2, where:

0 = one directory containing all the cache files

1 = a separate directory under the cache directory

2 = an additional sub directory for cached content under the cache directory

The Data Cache Lock-On-Expire feature reduces the load spike of a busy application by guaranteeing that an application gathers an expired piece from the data source only once, and by avoiding a situation where multiple PHP processes simultaneously detect that the data in the cache has expired, and repeatedly run high-cost operations.

How does it work?

When a stored Data Cache entry expires, the following process takes place:

1. The first attempt to fetch it will receive a 'false' response.

2. All subsequent requests will be receiving the expired object stored in the Data Cache for the duration of 120 seconds.

3. During this time period, the php script that received the 'false' response generates an updated data entry and stores it in the Data Cache with the same key.

4. As soon as the updated data entry is created, it is returned to the subsequent fetching requests.

5. If this does not occur within the time period of 120 seconds, the entire process (1-4) will repeat itself.

This feature is controlled by directive zend_datacache.lock_on_expire in 'datacache.ini'.

The accepted values for this directive are 0 and 1, where:

1 = Enabled (default)

0 = Disabled.

Note:

If set to 0, any request for an expired data entry will receive a 'false' response until a new value is set. To ensure enhanced performance, it is recommended that the default settings not be changed.

Note:

This mechanism exists from Zend Server version 9.1 onward.

When you run Data Cache API functions to delete or clear cached objects and namespaces in a clustered environment, you only need to run a single API call, which will set the same call on all cluster nodes (as a centralized task). The following Data Cache API calls supports cluster wide operation:

• zend_shm_cache_delete()
• zend_disk_cache_delete()
• zend_shm_cache_clear()
• zend_disk_cache_clear()

Note:

By default, delete and clear API calls will be signaling all cluster nodes to invalidate the objects and namespaces. If for some reason, only local copy should be dropped, you can pass clusterDelete=true in the function parameters, so a cluster matching task to other nodes will not be created.

This procedure describes how to configure the Zend Data Cache component.