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 2 Nächste Version anzeigen »

Brandbox verwendet Caches, die nachfolgend benannt werden. Um Fehler auszuschließen, ist es hilfreich, Caches zu leeren. Dazu navigieren Sie zu „Administration: Plugins“ und wählen „Caches leeren“.

OPcache

http://php.net/manual/de/book.opcache.php

Sollte der OPcache für Problem sorgen kann er in der Konfiguration von PHP FPM komplett deaktiviert werden (/etc/php/7.1/mods-available/brandbox.ini):

opcache.enable=0


Anschließend den Service neustarten:

service php7.1-fpm restart


Eine manuelle Leerung des Caches ist per Konsole durch Neustarten des PHP-Service möglich:

service php7.1-fpm restart


Siehe auch: /wiki/spaces/DEVOPS/pages/27448350

PHP (Object-Cache)

Brandbox cached einige Methoden mittels APCu oder wahlweise Redis.

Beispiel
use brandbox\component\cache;

$cache = cache\provider::get();

$html .= $cache->remember(
  [__METHOD__, 'individueller-cache-key'],
  function () use ($something) {
    return 'cache-value';
  },
  $cacheTTL,
  'brandbox/shop-core'
);

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