Das System von Magento ermöglicht es Entwickler, Daten die oft abgerufen werden im Cache zwischenzuspeichern. Angefangen von Config-Dateien über Layout Updates, aber natürlich auch der HTML Code der Templates kann aus dem Cache abgerufen werden. Die Verwendung ist denkbar einfach, hat aber auch Tücken, die zu Einbußen in der Usability führen können.

Die einzelnen Varianten des Cache möchte ich hier nicht bescheiben, aber generell wird dazu das Model von Zend_Cache verwendet. Flimmit verwendet momentan noch die Basis Einstellung von Magento – den filebasierten Cache im Verzeichnis “/var/cache/”. Hier ist sicher noch ein Geschwindigkeits-Vorteil rauszuholen, wenn man die Memcached Variante verwendet.

Die allgemeine Einstellung von Magento hat Caching im Bereich der HTML-Blöcke sehr restriktiv eingestellt. Hier kann die Ladezeit noch erhöht werden,  indem für Produktseiten bzw. Katalogseiten das Frontend Caching (“Blocks HTML output”) aktiviert. Generell kann für jeden Block ein CacheKey und mehrer CacheTags definiert werden. Meist passiert dies gleich im Konstrutor des Blocks:

$this->addData(array(
‘cache_lifetime’=> false,
‘cache_key’=>’12345′
‘cache_tags’    => array(Mage_Core_Model_Store::CACHE_TAG, Mage_Cms_Model_Block::CACHE_TAG)
));

Das Caching greift aber erst, wenn der Wert von ‘cache_lifetime’ vorhanden ist. Wenn dieser auf “false” gesetzt wird, bedeutet dies nur, dass der Cache ewig gültig ist (gerade passend für Bereiche, die sich selten ändern). Der CacheKey ist der eindeutige Identifier, der Zugriff auf das Cachefile erlaubt bzw. über den ein speielles Cachefile gelöscht werden kann. Mit den CacheTags kann über ein oder mehrere Tags der Cache später über diese Tags gelöscht werden. Gerade das ist eine wichtige Info, auf die bei der Verwendung von Block-Cache geachtet werden sollte.

Die Definition des Zend_Cache für Filebasierten Cache bietet mehrere Parameter. Interessant ist für Magento die Verwendung von ‘hashed_directory_level’, sozusagen der Tiefe der Ordnerstruktur. Je mehr Cachefiles man erwartet, desto größer sollte der Wert sein. Sonst könnten die Zugriffszeiten auf die Cachefiles etwas länger werden.
Hier haben wir die Attribute noch erweitert, da die Maskierung der Dateien mit dem Standardwert 0700 belegt werden. Da aber in manchen Fällen z.B. ein Cronjob als andere User ausgeführt wird, kann es bei der Erneuerung des Caches zu Zugriffsproblemen kommen.

Bei der ersten Verwendung des Caches lag die Herausforderung von flimmit bei der unterschiedlichen Darstellung der Kaufoptionen für User aus verschiedenen Ländern. Da manche unserer Filme territorial eingegrenzt werden müssen, müsste theoretisch für die Produktseite für jeden Ländercode ein eigenes Cachefile erstellt werden. Bei hunderten Filmen und hunderten Ländern würde sich das bald potenzieren. Trotzdem ist die Frontend-Ebene für Caching die schnellste Variante, da nur mehr HTML-Code ausgegeben und kein PHP Code mehr innerhalb der Templates verarbeitet werden muss. Das beste Verhältnis zwischen Felxibilität und Performance muss jeder selber herausfinden.

Ein wichtiger Punkt in Zusammenhang mit dem Cache ist die Bearbeitung von Produktinformationen im Admin-Bereich. Ein wesentlicher Punkt in der Speicherung von Produktinformationen ist die Methode “cleanCache” im File “/app/code/core/Mage/Catalog/Model/Product.php”:

public function cleanCache()
{
Mage::app()->cleanCache(‘catalog_product_’.$this->getId());
return $this;
}

Hier wird der Cache anhand des Tags “‘catalog_product_’.$this->getId()” durchsucht und alle relevanten Files gelöscht. Für die Usability und Aktualität von Daten unumgänglich und notwendig. Hier 2 Tips:

1. Damit auch das Frontend nach jeder Produktänderung aktuell bleibt, sollte auch der Blockoutput (sofern hier das Caching angewendet wird) mit diesem Tag versehen werden. Dadurch ist garantiert, dass auch das Frontend immer die aktuellen Daten anzeigt.
2. Lassen Sie den Cache nie zu groß werden. Bei vielen tausend Files kann ein solcher Vorgang sogar mehr als eine Minute dauern. Und beim Speichern von einem Produkt wird die Methode “cleanCache” vor uns nach dem Speichern verwendet!
   Dazu bietet Zend_Cache eine Option, um “alte” (also abgelaufene) Cachefiles zu löschen.

Hier ein Beispiel, wie man eine Methode (ev. über einen Cronjob) periodisch den alten Cache löschen lassen kann:

public function cleanOldCache()
{
// clean only outdated
Mage::app()->getCache()->clean(Zend_Cache::CLEANING_MODE_OLD);
}

Somit ist unterm Strich die Verwendung von Zend_Cache im Rahmen von Magento ein tolle Sache, kann aber durch oben besagte Punkte auch zu ärger führen.

Ein kurzer Überblick zum Caching direkt bei Magentocommerce gibt es hier:
Magento Cache Management

Also, “happy e-commerce”
Walter