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:

Example: 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 (3) 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.

	Example: This example shows how to manipulate variable caching using a 'namespace' zend_disk_cache_store("my_namespace::my_key",$data) is fetched with zend_disk_cache_fetch("my_namespace::my_key"); zend_shm_cache_clear("my_namespace") clears all the keys that start with "my_namespace::"

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.

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

	To configure the component: In the UI, go to Configurations | Components. From the Components list, select the component. The Expanded view will display the directives associated with the component. Review the assorted directives and their descriptions, and configure the component according to your personal preferences. For information on how to configure directives, see Working with Components. In the Action bar, click . In the toolbar, the restart icon lights up , indicating a restart is needed to apply changes. Click to restart server and apply changes. For information on restarting in Zend Server, see Server Restart.
For information on configuring the component daemon directives, see Configuring Component Daemon Directives (Zend Session Clustering, Zend Deployment, Zend Java Bridge, Zend Job Queue, and Zend Monitor).