Redspark_Cache
Easier usage of Zend_Cache
Redspark_Cache
The redspark cache uses the frontend/backend concept of Zend_Cache an makes the usage easier. There is a broker, which is responsible for finding the right cache backend for your frontend. It takes care of enabled and disabled cache and handles all cache tags independent of the used backend.
Configuring the cache
All configruations, enabling or disabling backends/frontends/tags etc. are inside the [Cache]-Section of the main configuration. It is hardly recommended to enable the memcache via develop.ini. This allows the system to cache config files inside the memcache at a very early state of bootstrapping.
A list of available options can be found inside the configuration file under library/redspark/latest/Redspark/RsApplication/Config/Default/Cache.ini.
Cache Handler
The Cache Handler is a kind of broker for easier access to cache-related stuff like adding, delivering or cleaning.
Such tasks can be done by a single line of code:
<?php
Broker::getCache()->addMemcache($my_data,'my_key');
?>
<?php
$my_data = Broker::getCache()->deliverMemcache('my_key');
?>
Cleaning differnt Backends from one tag is more easier, too:
Broker::getCache()->purgeTags(Array('my_tag'));
Example code caching
This example tries to deliver a cache "my_key". If this fails, the cache is built and stored.
<?php
$data = Broker::getCache()->deliverMemcache('my_key');
if (is_null($data)) {
$data = MyStuff();
Broker::getCache()->addMemcache($data,'my_key');
}
?>
Cache Backends
There are mainly four backends, used in redspark. Two of them (memcached and file) come from zend and are just a bit configured and extend. The other two (static and proxy) are redspark developments and described later on. Additionally to this new backends there is an interface, for implementing the counting of cache entries, which is implemented in all four backends. Last but not least, there is an abstracting for implementing tagging support in Backends that will not support it else. It is used inside the proxy and the static backend.
Proxy Backend
The Proxy backend depends on a reverse proxy server, located between the web server and the client. The main purpose of the according cache backend is as follows:
- Sending right headers:
It is not easy to send the right headers, so the client will not cache some data, but the proxy will. - Add tagging support
This is the only way to allow aggressive caching as it gives you the possibility to select special entries for purging. - Purging entries off the proxy
Via http PURGE request, data located inside the proxy can be removed. - (Etagging support)
Etagging could help to let the proxy assume, that the data didn't change, without having a local copy of the data itselfs.
Static Backend
The Backend static allows you to save a copy of the just generated HTML in a subfolder of htdocs/static.
This will lead to a very fast deliverance of data from the webserver itself via .htaccess rule, not needing any php code.
Of course this makes only sense, when no dynamic data is located inside the page. Otherwise, the action will be your friend.
