Die Cache-Komponente (Brandbox/Cache) implementiert PSR-6 für größtmögliche Interoperabilität. Hinter einer Fasade wird die Cache Component von Symfony verwendet.
Weiterlesen unter https://symfony.com/doc/current/components/cache.html
Folgende Caches stehen in brandbox zur Verfügung.
PHP (Object-Cache)
Brandbox cached einige Methoden mittels APCu oder wahlweise Redis.
use Brandbox\Framework\Brandbox\Cache; $cache = Cache\Provider::get(); $callback = function () use ($something) { return 'cache-value'; }; $cacheTtl = 86400; // 1 Tag $namespace = 'brandbox/shop-core'; $html .= $cache->remember( [__METHOD__, '{cache-tag}'], $callback, $cacheTtl, $namespace );
Doctrine – Second-Level-Cache
Der Second-Level-Cache wird verwendet, wie hier beschrieben: https://www.doctrine-project.org/projects/doctrine-orm/en/2.6/reference/second-level-cache.html
Der Second-Level-Cache ist standardmäßig ausgeschaltet und muss in der config.php explizit aktiviert werden. Da die Verwendung des Second-Level-Cache ohne Redis Inkonsistenzen beim Betrieb mit mehreren Pods verursachen kann, muss er für die Verwendung mit APC explizit über einen weiteren Parameter aktiviert werden:
/** * Cache */ 'cache' => [ 'doctrine' => true, // Second-Level-Cache einschalten 'doctrine-apc' => true // Second-Level-Cache für die Verwendung mit APC einschalten ]
Wird der Second-Level-Cache genutzt, müssen Doctrine-Entities entsprechend gekennzeichnet werden:
/** * @Entity(repositoryClass="brandbox\my\repository\myEntity") * @Cache(usage="NONSTRICT_READ_WRITE", region="brandbox") * @Table(name="content_my_entity") * **/ class myEntity {
Connection
In der Connection wird der Cache aktiviert: \Brandbox\Framework\Brandbox\Doctrine\Lib\Connection\Connection::enableSecondLevelCache
Repository
Hier wird der Cache für die Standard-Repositories und -Queries aktiviert: \Brandbox\Framework\Brandbox\Doctrine\Lib\Repository\RepositoryAbstract::createQueryBuilder
Cacheable oder nicht
Ein Query ist Cacheable wenn ein Entity im Result ausgeliefert wird. Ist das nicht der Fall, kommt es zum Fehler (WSOD). Man erkennt das an der Hydration.
Letztlich ist „nur“ dieses Objekt cacheable: \Doctrine\ORM\AbstractQuery::HYDRATE_OBJECT
Evict
Wird ein Datensatz verändert (DELETE, INSERT, UPDATE) muss der verändernde Query ein Hint erhalten:
$qb ->delete($class, $identifier) ->where($expr->eq($identifier . '.id', ':id')) ->setParameter(':id', $id) ->getQuery() ->setHint(ORM\Query::HINT_CACHE_EVICT, true) ->execute() ;
Redis
Um Caches zentral zu verwalten, steht eine Schnittstelle zu Redis zur Verfügung. Redis wird in der config.php eingerichtet und dadurch aktiviert. Dieser wird benötigt, sofern mehr als ein Application-Container genutzt wird.
/** * Redis */ 'redis' => [ 'host' => getenv('REDIS_HOST'), 'port' => getenv('REDIS_PORT'), ]
Die Umgebungsvariablen REDIS_HOST und REDIS_PORT werden automatisch über den /wiki/spaces/DEVOPS/pages/27452604 gesetzt, sofern die Variable DEPLOYMENT_REDIS_USE aktiviert ist. In der Robhost/Rancher-Umgebung wird zeitgleich ein redis-Container aktiviert.
Eventübersicht
Klassenname | Beschreibung |
---|---|
OnFlushDataset | Wird Cache\FlushDataset::class ausgelöst. Es steht damit eine zentrale Methode zur Verfügung, die es ermöglicht Datensatz-Caches zu leeren. |