Caching: die Ebenen und wie man sie invalidiert #

Diese Seite richtet sich an Entwickler, die eine Cache-Komponente verwenden (Symfony Cache, Cache von Laravel, das Cache-Framework von Django, Rails.cache von Rails). Exponential hat mehrere Caches, jeder mit einer ID und Tags, verwaltet von eZCache (kernel/classes/ezcache.php), und die meisten davon invalidiert der Kernel, wenn Inhalte veröffentlicht werden. Der übliche Grund für „meine Änderung erscheint nicht“ ist eine dieser Ebenen (Caches).

Inhalt #

1. Die Ebenen
2. Leeren
3. Fragment-Caching in Templates
4. Daten in PHP cachen
5. Unter persistenten Workern
6. Im Vergleich mit anderen Frameworks

Die Ebenen #

Das Caching von Inhalts-Views steuert site.ini [ContentSettings] ViewCaching (mitgeliefert: enabled). Die vollständige Liste mit IDs und Tags: Anleitung zu Caches.

Leeren #

php bin/php/ezcache.php --clear-tag=ini --allow-root-user
php bin/php/ezcache.php --clear-id=template-override --allow-root-user
./console exp:cache status
./console exp:velocity deploy          # the usual way after a code change: everything in the right order

exp:velocity deploy leert die Caches in einer Reihenfolge, die so gewählt ist, dass eine von altem Code gerenderte Seite nie erneut gecacht wird (Server und Deployment). Eine Erweiterung kann ihren eigenen Cache mit site.ini [Cache] CacheItems[] und einem [Cache_<id>]-Block in die Liste aufnehmen, sodass ezcache.php und Setup > Caches ihn leeren können.

Fragment-Caching in Templates #

{cache-block keys=array( 'expdemo-stats', $current_user.contentobject_id ) expiry=300}
  {def $stats = fetch( 'expdemo', 'stats', hash() )} ... {undef $stats}
{/cache-block}

Daten aus Ihren eigenen Tabellen lösen das Leeren beim Veröffentlichen nicht aus: Wählen Sie ein expiry, oder verwenden Sie ignore_content_expiry und leeren Sie den template-block-Cache selbst, wenn sich Ihre Daten ändern. Bilden Sie den Schlüssel aus allem, wovon die Ausgabe abhängt, einschließlich des Benutzers, wenn das Fragment persönlich ist (Template-Caches).

Daten in PHP cachen #

Im Kernel gibt es keinen Cache-Pool nach PSR-6 oder PSR-16. Aufwendige Ergebnisse werden über den Cluster-Datei-Handler gespeichert, sodass sie auf einem einzelnen Server und in einem Cluster funktionieren:

$file = eZClusterFileHandler::instance( eZSys::cacheDirectory() . '/expdemo/stats.cache' );
$stats = $file->processCache(
    function ( $path, $mtime ) { return json_decode( (string)file_get_contents( $path ), true ); },
    function ( $path ) {
        $stats = expDemoStats::compute();
        return array( 'content' => $stats, 'binarydata' => json_encode( $stats ), 'scope' => 'expdemo-stats' );
    },
    300 );

Während ein Prozess die Daten erzeugt, warten die anderen, statt dieselben Daten ebenfalls zu erzeugen (Caching in Anwendungen). Cache-Dateien müssen über eZClusterFileHandler::instance() geschrieben werden, nicht mit direkten Dateiaufrufen. Mit der Erweiterung sevenx_valkey_cache hält eine Installation den Content-View-Cache und den kompilierten INI-Cache in Valkey oder Redis (sevenx_valkey_cache).

Unter persistenten Workern #

Velocity hält PHP-Prozesse zwischen Requests am Leben: Eine statische Variable überlebt bis in den nächsten Request. Halten Sie niemals benutzerspezifische Daten in statischen Variablen; der Prozessspeicher wird zwischen Workern nicht geteilt, er ist also auch kein gemeinsamer Cache.

Im Vergleich mit anderen Frameworks #

Der entscheidende Unterschied: Inhalts-Caches werden durch das Veröffentlichen invalidiert, automatisch und pro Knoten; Ihre eigenen Daten brauchen einen expliziten Ablauf oder ein explizites Leeren.

Verwandte Seiten #

• HTTP-Caching und Reverse-Proxies
• View-Cache und Cache-Blöcke
• Cache-Konsole
• Freie Dokumentation: Diese Seite darf unter der GNU FDL 1.3 frei kopiert, übersetzt und verbessert werden.