Flush Magento Cache sagt vereinfacht: Lösche die Cache Einträge, von denen Magento weiß, dass sie zu Magento gehören.

bin/magento cache:clean

bzw.

bin/magento c:c

Magento räumt also seine eigenen Cache Daten auf, lässt den verwendeten Cache Speicher selbst aber bestehen.

Flush Cache Storage sagt dagegen: Leere den gesamten Cache Speicher, den Magento gerade verwendet.

bin/magento cache:flush

bzw.

bin/magento c:f

Am einfachsten lässt es sich mit einer Schublade vergleichen: cache:clean nimmt nur die Magento Sachen aus der Schublade. cache:flush kippt den kompletten Inhalt der Schublade aus. Danach ist die Schublade leer.

Das wird beispielsweise bei Redis wichtig. Nutzt noch eine andere Anwendung denselben Redis Speicher, kann Flush Cache Storage auch deren Cache Daten entfernen.

Für das normale Cache Leeren reicht deshalb in der Regel Flush Magento Cache. Flush Cache Storage ist die gröbere Variante und sinnvoll, wenn wirklich der gesamte verwendete Cache Speicher geleert werden soll.

Für eine temporäre Analyse kann beispielsweise ein Plugin auf TypeList::cleanType() und Cache Manager::flush() gesetzt werden. Die Registrierung erfolgt in der etc/di.xml:

<?xml version="1.0"?>
<config xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        xsi:noNamespaceSchemaLocation="urn:magento:framework:ObjectManager/etc/config.xsd">

    <type name="Magento\Framework\App\Cache\TypeList">
        <plugin name="cache_trace_type_list"
                type="Vendor\Module\Plugin\CacheTrace"/>
    </type>

    <type name="Magento\Framework\App\Cache\Manager">
        <plugin name="cache_trace_manager"
                type="Vendor\Module\Plugin\CacheTrace"/>
    </type>

</config>

Das Plugin protokolliert neben dem betroffenen Cache Typ auch den Aufrufpfad:

<?php

declare(strict_types=1);

namespace Vendor\Module\Plugin;

use Magento\Framework\App\Cache\Manager;
use Magento\Framework\App\Cache\TypeList;
use Magento\Framework\Filesystem\DirectoryList;

class CacheTrace
{
    public function __construct(
        private readonly DirectoryList $directoryList
    ) {
    }

    public function beforeCleanType(
        TypeList $subject,
        string $typeCode
    ): array {
        $this->writeTrace('CLEAN', [$typeCode]);

        return [$typeCode];
    }

    public function beforeFlush(
        Manager $subject,
        array $types
    ): array {
        $this->writeTrace('FLUSH', $types);

        return [$types];
    }

    private function writeTrace(string $action, array $types): void
    {
        $trace = debug_backtrace(
            DEBUG_BACKTRACE_IGNORE_ARGS,
            25
        );

        $lines = [];

        foreach ($trace as $entry) {
            $call = ($entry['class'] ?? '')
                . ($entry['type'] ?? '')
                . ($entry['function'] ?? '');

            $location = isset($entry['file'])
                ? $entry['file'] . ':' . ($entry['line'] ?? '')
                : '';

            $lines[] = $call . ' ' . $location;
        }

        $message = sprintf(
            "[%s] %s: %s\n%s\n\n",
            date('Y-m-d H:i:s'),
            $action,
            implode(', ', $types),
            implode("\n", $lines)
        );

        file_put_contents(
            $this->directoryList->getPath(DirectoryList::LOG)
                . '/cache-trace.log',
            $message,
            FILE_APPEND | LOCK_EX
        );
    }
}

Wird nun beispielsweise der full_page oder layout Cache geleert, landet der zugehörige Call Stack in var/log/cache-trace.log. Dort lässt sich häufig direkt erkennen, ob der Aufruf aus dem Magento Core, einem Cronjob oder einer bestimmten Extension stammt.

Interessant ist die Unterscheidung zwischen CLEAN und FLUSH. Beim Clean werden gezielt Magento Cache Typen bereinigt, während ein Flush den dahinterliegenden Cache Speicher betrifft.

Solch ein Trace sollte nur zur Fehlersuche eingesetzt und anschließend wieder entfernt werden. Gerade wenn ein Shop scheinbar grundlos regelmäßig z.B. seinen Full Page Cache verliert, kann er aber ziemlich schnell zeigen, wer den Cache tatsächlich leert.

Magento kann dabei für jedes Produkt und jede Store View einen eigenen Layout Cache Eintrag erzeugen. Bei beispielsweise 50.000 Produkten und mehreren Store Views kann die Anzahl dieser Cache Einträge entsprechend stark anwachsen.

Die Folge ist ein unnötig hoher Speicherverbrauch in Redis oder Valkey, obwohl die eigentlichen Produktdaten oder Besucherzahlen dies zunächst nicht erklären.

Betroffen sind Magento Open Source und Adobe Commerce ab Version 2.4.8 bis vor 2.4.10. Adobe stellt mit ACP2E-4908 einen Quality Patch für das Problem bereit.

Gerne unterstüzte ich Sie dabei, den Patch in Ihrem Magento 2 Shop zu installieren. Sollte eine andere Ursache vorliegen, schaue ich mir diese auch gerne an.

Während ein Block mit cacheable=”false” dazu führen kann, dass die gesamte Seite nicht mehr über den Full Page Cache ausgeliefert wird, bleibt die eigentliche Seite bei Private Content weiterhin cachebar, nur einzelne benutzerspezifische Bereiche werden separat geladen und dynamisch ausgegeben.

Typische Beispiele sind der Warenkorb, der Kundenname oder die Wunschliste.

Das Prinzip dahinter ist einfach zu erklären: Cachebarer Inhalt kommt aus dem Full Page Cache, individueller Inhalt wird unabhängig davon nachgeladen.

cacheable=”false” sollte daher nicht “einfach mal so” verwendet werden, nur weil ein einzelner Bereich dynamisch ist. Private Content ermöglicht in vielen Fällen die sauberere Lösung, ohne die Cache Wirkung der gesamten Seite zu verlieren.

Ein einfaches Beispiel ist eine eigene Customer Section. Die PHP Klasse liefert die individuellen Daten:

namespace Vendor\Module\CustomerData;

use Magento\Customer\CustomerData\SectionSourceInterface;

class Example implements SectionSourceInterface
{
    public function getSectionData(): array
    {
        return [
            'message' => 'Dieser Inhalt ist individuell'
        ];
    }
}

Die Section wird anschließend in der etc/frontend/di.xml registriert:

<type name="Magento\Customer\CustomerData\SectionPoolInterface">
    <arguments>
        <argument name="sectionSourceMap" xsi:type="array">
            <item name="example" xsi:type="string">Vendor\Module\CustomerData\Example</item>
        </argument>
    </arguments>
</type>

Unter Hyvä stehen die Customer Sections über das Ereignis private-content-loaded zur Verfügung:

<div
    x-data="{ message: '' }"
    @private-content-loaded.window="
        message = $event.detail.data.example?.message || ''
    "
>
    <span x-text="message"></span>
</div>

Die Seite selbst bleibt dabei im Full Page Cache. Nur die Daten der Customer Section werden unabhängig davon im Browser bereitgestellt und können individuell für den jeweiligen Besucher ausgegeben werden.

Ein typischer Kandidat ist cacheable=”false”:

<block class="Vendor\Module\Block\Example"
       name="example"
       template="Vendor_Module::example.phtml"
       cacheable="false"/>

Befindet sich ein solcher Block auf der Seite, betrachtet Magento die gesamte Seite als nicht vollständig cachebar. Das kann dazu führen, dass selbst eine ansonsten normale Produkt oder Kategorieseite bei jedem Aufruf erneut aufgebaut wird.

Gerade bei Drittanbieter Extensions oder älteren individuellen Anpassungen lohnt sich deshalb die Suche nach cacheable=”false”, wenn der Full Page Cache scheinbar nicht greift. Das Attribut wird manchmal verwendet, um dynamische Inhalte auszugeben, obwohl dafür eigentlich andere Magento Mechanismen wie Private Content vorgesehen sind.

Typische Cache Tags sehen beispielsweise so aus:

cat_p_123
cat_c_42
cms_p_5

Der Aufbau ist dabei recht simpel: Der vordere Teil beschreibt den Typ der Entität, die Zahl dahinter ist normalerweise deren Entity ID. cat_p_123 steht also für das Produkt mit der ID 123, cat_c_42 für die Kategorie mit der ID 42 und cms_p_5 für die CMS Seite mit der ID 5.

Magento definiert diese Präfixe direkt an den jeweiligen Entitäten, beim Produkt zum Beispiel über cat_p. Die konkrete ID wird anschließend angehängt, sodass ein eindeutiger Cache Tag entsteht.

Wird anschließend beispielsweise Produkt 123 geändert, kann Magento gezielt Cache Einträge mit cat_p_123 ungültig machen, anstatt jedes Mal den kompletten Full Page Cache zu verwerfen. Bei Varnish werden diese Informationen zusammen mit dem gecachten Objekt verwendet, damit später genau die betroffenen Inhalte entfernt werden können.

Die Tags entstehen unter anderem über Magentos IdentityInterface und dessen Methode getIdentities(). Auch eigene Blöcke und Module können darüber festlegen, von welchen Daten ihr gecachter Inhalt abhängig ist.

Auch bei cachebaren GraphQL Abfragen verwendet Magento diese Cache Tags, damit beispielsweise Produkt, Kategorie oder CMS Daten gezielt invalidiert werden können.

Fehlen solche Abhängigkeiten bei einer individuellen Entwicklung oder sind sie falsch gesetzt, kann ein besonders unangenehmer Fehler entstehen: Der Cache funktioniert, liefert nach einer Änderung aber weiterhin veraltete Inhalte aus.

Bei Templates helfen die Magento Template Hints dabei herauszufinden, welche .phtml Datei und welcher Block tatsächlich für einen Bereich verwendet werden. Einfach den folgenden Befehl im CLI ausführen und das Frontend erneut aufrufen.

bin/magento dev:template-hints:enable

Bei PHP Klassen ist dev:di:info hilfreich, da Magento damit unter anderem die tatsächlich verwendete Preference und vorhandene Plugins für eine Klasse anzeigt.

bin/magento dev:di:info 'Magento\Catalog\Block\Product\View'

Bei Änderungen an PHP Klassen, Preferences oder Plugins kann insbesondere im Production Mode außerdem eine erneute Kompilierung notwendig sein.

bin/magento setup:di:compile

Magento erzeugt dabei unter anderem Proxies, Factories und Interceptor Klassen neu. Wird noch alter generierter Code verwendet, kann sich eine Änderung deshalb trotz geleertem Cache scheinbar nicht auswirken.

Gerade bei Erweiterungen und individuellen Anpassungen kann dadurch schnell auffallen, dass nicht die erwartete Core Klasse ausgeführt wird, sondern eine Preference oder ein Plugin eingreift. Bei Templates kommen zusätzlich Theme Overrides und der Magento Fallback Mechanismus ins Spiel, weshalb ein einfaches bin/magento cache:flush nicht jedes Problem dieser Art lösen kann.

Wenn Änderungen trotz geleertem Cache nicht erscheinen, sollte deshalb zuerst geklärt werden, welcher Code tatsächlich ausgeführt wird und aus welchem Modul oder Theme er stammt.

Valkey ist Redis kompatibel, trotzdem sollte vor einem Magento Update geprüft werden, wie Cache und Sessions im bestehenden Shop konfiguriert sind und ob der Server bereits für Magento 2.4.9 vorbereitet ist.

Ich prüfe Ihre Magento Installation und sage Ihnen, ob und welche Änderungen für Valkey notwendig sind und führe die Anpassung auch gerne für Sie durch. Melden Sie sich gerne und ich schaue mir Ihren Shop und Ihren Server genauer an.

1. Wechsel in den Developer Modus:

php bin/magento deploy:mode:set developer

Hierbei wäre zu beachten, dass der Shop dadurch einen Moment nicht erreichbar sein könnte, da Magento 2 den Code neu generiert. Der bessere Weg, um Caches in Magento 2 zu aktivieren oder zu deaktivieren ist Lösung 2:

2. Caches direkt per CLI aktivieren / deaktivieren

php bin/magento cache:status           # Zeigt alle Cache Typen und den jeweiligen Status, z.B. "graphql_query_resolver_result"
php bin/magento cache:enable <Typ>     # Aktiviert einen oder mehrere Cache Typen
php bin/magento cache:disable <Typ>    # Deaktiviert einen oder mehrere Cache Typen
php bin/magento cache:clean            # Löscht den Magento Cache
php bin/magento cache:flush            # Leert andere Caches (z.B. Redis oder Filesystem)

Mit den oben genannten 2 Punkten können Sie nun optimal den Status Ihrer Magento 2 Caches steuern.

php -r 'require "app/Mage.php"; Mage::app()->getCacheInstance()->flush();'