Zum Ende der Metadaten springen
Zum Anfang der Metadaten

Sie zeigen eine alte Version dieser Seite an. Zeigen Sie die aktuelle Version an.

Unterschiede anzeigen Seitenhistorie anzeigen

« Vorherige Version anzeigen Version 5 Nächste Version anzeigen »

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. 

Folgende Caches stehen in brandbox zur Verfügung.

PHP (Object-Cache)

Brandbox cached einige Methoden mittels APCu oder wahlweise Redis.

Beispiel
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:

config.php
/**
  * 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:

config.php
/**
* @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:

Beispiel
$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.

config.php
/**
  * 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

KlassennameBeschreibung
OnFlushDatasetWird Cache\FlushDataset::class ausgelöst. Es steht damit eine zentrale Methode zur Verfügung, die es ermöglicht Datensatz-Caches zu leeren.
  • Keine Stichwörter