Exception_Warning: Declaration of RedSparkFramework_RsModule_Cms_Controller_Asset_IncParsedHtmlFile::getFormArray() should be compatible with that of RedSparkCore_RsModule_Cms_Controller_Asset_ListExtended::getFormArray()
Exception_Model: SQLSTATE[42S22]: Column not found: 1054 Unknown column 'c.name' in 'field list'
Try create Table
Exception_Model: SQLSTATE[42000]: Syntax error or access violation: 1064 You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near ') AND fk_account = '1' AND enabled IN ('Y', 'M', 'TM', 'T',' at line 23

Redspark_Cache

Easier usage of Zend_Cache

Zend_Cache already brings a feature-rich cache with it. Redspark takes it and helps the user to simply store or fetch some data with it.

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');
?>
The deliverance of the cache is easy, too:
<?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 cache will be your friend.

To enable a fine granularity of cache purging, sidecar files for each static cache entry must be written. They reside unter temp/<App>/cache/. A sidecar file exists for

  • Mapping Tags to files
  • Mapping files to tags
  • TTL for files
  • stale entries

Tutorials

Kuborgh GmbH

Hamburg 040 819 773 770 Köln 0221 276 66 96 info@kuborgh.de www.kuborgh.de

RedSpark Community

RedSpark Community

Community Website
RedSpark Apps

RedSpark Apps

Zur Übersicht
RedSpark Download

RedSpark Basispaket

Zum Download
Key facts