[On-Premises]{class="badge informative" title="Gilt nur für Adobe Commerce On-Premise-Projekte."}

L2-Cache-Konfiguration zur Leistungsoptimierung

L2-Caching (auf zwei Ebenen) reduziert den Netzwerkverkehr zwischen dem Remote-Cache-Service und der Commerce-Anwendung, indem auf jedem Webknoten eine lokale Cache-Ebene hinzugefügt wird. Eine standardmäßige Commerce-Instanz kann etwa 300 KB pro Anfrage übertragen. Bei hohen Anforderungsvolumina kann der resultierende Netzwerkverkehr erheblich sein.

Beim L2-Caching speichert jeder Web-Knoten häufig aufgerufene Daten lokal und verwendet den Remote-Cache für zwei Zwecke:

Commerce speichert die Hash-Datenversion im Remote-Cache, wobei das Suffix :hash an den regulären Schlüssel angehängt wird. Wenn der lokale Cache veraltet ist, werden die Daten über einen Cache-Adapter vom Remote-Cache-Service abgerufen.

Die verfügbare L2-Cache-Implementierung hängt von der Commerce-Version und der Patch-Ebene ab:

Konfiguration des RemoteSynchronizedCache L2-Cache

Die Anweisungen zur Cache-Konfiguration hängen von Ihrer Commerce-Version ab:

Für lokale Adobe Commerce-Versionen, die Redis unterstützen, verwenden Sie das folgende Beispiel, um den vorhandenen Cache-Abschnitt in der app/etc/env.php-Datei zu ändern oder zu ersetzen.

'cache' => [
    'frontend' => [
        'default' => [
            'backend' => '\\Magento\\Framework\\Cache\\Backend\\RemoteSynchronizedCache',
            'backend_options' => [
                'remote_backend' => '\\Magento\\Framework\\Cache\\Backend\\Redis',
                'remote_backend_options' => [
                    'persistent' => 0,
                    'server' => 'localhost',
                    'database' => '0',
                    'port' => '6379',
                    'password' => '',
                    'compress_data' => '1',
                ],
                'local_backend' => 'Cm_Cache_Backend_File',
                'local_backend_options' => [
                    'cache_dir' => '/dev/shm/'
                ]
            ],
            'frontend_options' => [
                'write_control' => false,
            ],
        ]
    ],
    'type' => [
        'default' => ['frontend' => 'default'],
    ],
]

Dabei gilt:

Für Adobe Commerce-Versionen vor 2.4.9, die Redis oder Valkey unterstützen, empfiehlt Adobe die Verwendung von Redis oder Valkey für das Remote-Caching, wie von der exakten Version unterstützt, und Cm_Cache_Backend_File für das lokale Caching. Der lokale Cache wird normalerweise in einem temporären Dateisystem gespeichert, z. B. /dev/shm/:

'local_backend_options' => [
    'cache_dir' => '/dev/shm/'
]

Adobe empfiehlt die Verwendung der [cache preload](redis-pg-cache.md#redis-preload-feature)-Funktion, da dadurch die Redis-Last reduziert wird. Stellen Sie sicher, dass Sie das Suffix :hash für Vorabladeschlüssel hinzufügen.

Veraltete Cache-Optionen

Ab Commerce 2.4 kann die use_stale_cache-Option in bestimmten Fällen die Leistung verbessern, indem zuvor zwischengespeicherte Daten bereitgestellt werden, während in einem parallelen Prozess neue Cache-Daten generiert werden. Die in diesem Abschnitt beschriebenen empfohlenen Cache-Typen und Kompromisse gelten sowohl für die RemoteSynchronizedCache- als auch für symfony_l2. Ein Beispiel für eine symfony_l2 Konfiguration finden Sie unter Symfony L2-Cache mit veraltetem Cache.

Im Allgemeinen ist der Kompromiss mit Sperrwartung aus Sicht der Leistung akzeptabel. Je mehr Blöcke oder Cache-Einträge vorhanden sind, desto länger dauert die Sperrwartung. In einigen Szenarien kann die Wartezeit für den Prozess bis zu die Anzahl der Schlüssel x Lookup-) betragen. In seltenen Fällen kann ein Benutzer Hunderte von Schlüsseln im Block/Config-Cache haben, sodass selbst ein kleines Lookup-Timeout für eine Sperre Sekunden kosten kann.

Adobe empfiehlt, die Option use_stale_cache nur für Cache-Typen zu aktivieren, die am meisten davon profitieren, darunter:

Es wird von Adobe nicht empfohlen, die Option use_stale_cache für den default Cache-Typ zu aktivieren.

Der folgende Code zeigt eine Beispielkonfiguration für das RemoteSynchronizedCache-Backend. Ein symfony_l2 Beispiel finden Sie unter Symfony L2 Cache with Stale Cache.

'cache' => [
    'frontend' => [
        'default' => [
            'backend' => '\\Magento\\Framework\\Cache\\Backend\\RemoteSynchronizedCache',
            'backend_options' => [
                'remote_backend' => '\\Magento\\Framework\\Cache\\Backend\\Redis',
                'remote_backend_options' => [
                    'persistent' => 0,
                    'server' => 'localhost',
                    'database' => '0',
                    'port' => '6379',
                    'password' => '',
                    'compress_data' => '1',
                ],
                'local_backend' => 'Cm_Cache_Backend_File',
                'local_backend_options' => [
                    'cache_dir' => '/dev/shm/'
                ]
            ],
            'frontend_options' => [
                'write_control' => false,
            ],
        ],
         'stale_cache_enabled' => [
            'backend' => '\\Magento\\Framework\\Cache\\Backend\\RemoteSynchronizedCache',
            'backend_options' => [
                'remote_backend' => '\\Magento\\Framework\\Cache\\Backend\\Redis',
                'remote_backend_options' => [
                    'persistent' => 0,
                    'server' => 'localhost',
                    'database' => '0',
                    'port' => '6379',
                    'password' => '',
                    'compress_data' => '1',
                ],
                'local_backend' => 'Cm_Cache_Backend_File',
                'local_backend_options' => [
                    'cache_dir' => '/dev/shm/'
                ],
                'use_stale_cache' => true,
            ],
            'frontend_options' => [
                'write_control' => false,
            ],
        ]
    ],
    'type' => [
        'default' => ['frontend' => 'default'],
        'layout' => ['frontend' => 'stale_cache_enabled'],
        'block_html' => ['frontend' => 'stale_cache_enabled'],
        'reflection' => ['frontend' => 'stale_cache_enabled'],
        'config_integration' => ['frontend' => 'stale_cache_enabled'],
        'config_integration_api' => ['frontend' => 'stale_cache_enabled'],
        'full_page' => ['frontend' => 'stale_cache_enabled'],
        'translate' => ['frontend' => 'stale_cache_enabled']
    ],
],

Symfony L2-Cache-Implementierung

Verwenden Sie in Commerce ab Version 2.4.9 die Symfony L2-Cache-Implementierung (symfony_l2-Backend) anstelle von RemoteSynchronizedCache. Der Symfony L2-Cache bietet eine PSR-6-konforme Caching-Implementierung mit Valkey.

Migration von RemoteSynchronizedCache zu Symfony L2

Wenn Sie ein Upgrade einer On-Premise-Installation vom RemoteSynchronizedCache-Backend auf symfony_l2 durchführen, überprüfen Sie Folgendes, bevor Sie app/etc/env.php aktualisieren. Es reicht nicht aus, nur den backend zu ändern. Die Konfigurationsstruktur, die Schlüsselnamen und einige Standardverhaltensweisen unterscheiden sich.

Konfigurationsbeispiel mit Symfony L2-Cache

Verwenden Sie in der app/etc/env.php-Datei den vereinfachten symfony_l2-Backend-Typ für den L2-Cache. Dieses Beispiel umfasst nicht die preload_keys Konfiguration, was bei symfony_l2 nicht empfohlen wird. Weitere Informationen finden Sie unter Migration von RemoteSynchronizedCache zu Symfony L2.

Im Beispiel wird cleanup_percentage auf 90 gesetzt. Der Standardwert ist 95. Passen Sie diesen Wert entsprechend dem verfügbaren lokalen Cache-Speicher und den Anforderungen Ihrer Commerce-Bereitstellung an.

'cache' => [
    'frontend' => [
        'default' => [
            'backend' => 'symfony_l2',
            'backend_options' => [
                // L2 (Remote): Valkey with Symfony Cache
                'remote_backend' => 'valkey',
                'remote_backend_options' => [
                    'server' => 'localhost',
                    'database' => '0',
                    'port' => '6379',
                    'password' => '',
                    'serializer' => 'igbinary',
                    'compression_lib' => 'gzip',
                    'compress_data' => '1',
                    'persistent_id' => 'magento_l2_default',
                    'timeout' => '2.5',
                    'read_timeout' => '2.0',
                    'use_lua' => '1',
                ],
                // L1 (Local): File cache
                'local_backend' => 'file',
                'local_backend_options' => [
                    'cache_dir' => '/dev/shm/magento_l1'
                ],
                'cleanup_percentage' => 90,
            ],
        ]
    ],
    'type' => [
        'default' => ['frontend' => 'default'],
    ],
],

Symfony L2-Cache mit veraltetem Cache

Siehe Veraltete Cache-Optionen, für welche Cache-Typen von veraltetem Cache profitieren und warum.

Verwenden Sie das folgende Beispiel, um separate Frontends für symfony_l2 Unterstützung veralteter Caches zu konfigurieren:

'cache' => [
    'frontend' => [
        // Default frontend: NO stale cache
        'default' => [
            'backend' => 'symfony_l2',
            'backend_options' => [
                'remote_backend' => 'valkey',
                'remote_backend_options' => [
                    'server' => 'localhost',
                    'database' => '0',
                    'port' => '6379',
                    'serializer' => 'igbinary',
                    'compression_lib' => 'gzip',
                    'compress_data' => '1',
                    'persistent_id' => 'magento_l2_default',
                ],
                'local_backend' => 'file',
                'local_backend_options' => [
                    'cache_dir' => '/dev/shm/magento_l1'
                ],
            ],
        ],
        // Stale cache enabled frontend
        'stale_cache_enabled' => [
            'backend' => 'symfony_l2',
            'backend_options' => [
                'remote_backend' => 'valkey',
                'remote_backend_options' => [
                    'server' => 'localhost',
                    'database' => '0',
                    'port' => '6379',
                    'serializer' => 'igbinary',
                    'compression_lib' => 'gzip',
                    'compress_data' => '1',
                    'persistent_id' => 'magento_l2_stale',
                ],
                'local_backend' => 'file',
                'local_backend_options' => [
                    'cache_dir' => '/dev/shm/magento_l1_stale'
                ],
                'use_stale_cache' => true,
            ],
        ]
    ],
    'type' => [
        'default' => ['frontend' => 'default'],
        'layout' => ['frontend' => 'stale_cache_enabled'],
        'block_html' => ['frontend' => 'stale_cache_enabled'],
        'reflection' => ['frontend' => 'stale_cache_enabled'],
        'config_integration' => ['frontend' => 'stale_cache_enabled'],
        'config_integration_api' => ['frontend' => 'stale_cache_enabled'],
        'full_page' => ['frontend' => 'stale_cache_enabled'],
        'translate' => ['frontend' => 'stale_cache_enabled'],
    ],
],

Backend-Optionen für Symfony L2-Cache

Verbesserte Symfony L2-Cache-Leistung und Zuverlässigkeit

Die neuesten Aktualisierungen verbessern die Skalierbarkeit des Symfony L2-Cache, reduzieren unnötige Dateisystem-E/A und verbessern die Cache-Konsistenz und -Zuverlässigkeit.

Optimierter Symfony L2-Cache-Tag-Speicher

Bei Valkey-unterstützten Symfony L2-Cache-Bereitstellungen werden Cache-Tags ausschließlich in Valkey gespeichert. Dadurch werden redundante Tag-Index-Schreibvorgänge im Dateisystem eliminiert, Datenträger-E/A reduziert und unnötiges Wachstum des var/cache/symfony/tags/-Verzeichnisses verhindert.

Verbessertes dateibasiertes Cache-Verhalten

Bei Bereitstellungen mit dem dateibasierten Cache (ohne Valley) wird der lokale Tag-Index weiterhin gepflegt, um die Cache-Invalidierung zu unterstützen. Der Tag-Index wird jetzt in den konfigurierten cache_dir anstelle des zuvor hartcodierten var/cache-Speicherorts geschrieben, was eine konsistente Cache-Verzeichnisverwendung gewährleistet und die Unterstützung für benutzerdefinierte Cache-Konfigurationen verbessert.

Veraltete Tag-Mitgliedschaftskorrektur nach dem Retagging

Wenn Sie einen Cache-Eintrag erneut taggen, kann er mit Tags verknüpft bleiben, zu denen er nicht mehr gehört. Veraltete Tag-Mitgliedschaften werden jetzt beim erneuten Taggen gelöscht, sodass Cache-Einträge nur durch die ihnen derzeit zugewiesenen Tags ungültig gemacht werden.

Fehlerkorrektur - Redundante Remote-Schreibvorgänge für unveränderte Speichervorgänge

Beim Speichern eines Cache-Eintrags mit unverändertem Inhalt wird weiterhin ein Schreiben in das Remote-Backend (Valley) ausgelöst. Das Speichern wird jetzt übersprungen, wenn der Inhalt unverändert bleibt, wodurch unnötige Remote-Schreibvorgänge reduziert werden.

Größenbasierte Räumungskorrektur für L1 (cleanup_percentage)

Der cleanup_percentage Schwellenwert, der für die L1-größenbasierte Entfernung verwendet wurde, enthielt nicht konsistent Trigger-Bereinigung. Die L1-Cache-Entfernung berücksichtigt jetzt korrekt die konfigurierten cleanup_percentage.

Regenerationssperre für veralteten Cache

Wenn use_stale_cache aktiviert ist und die Remote-Kopie eines Eintrags vorübergehend nicht verfügbar ist, erhält jetzt nur ein Prozess eine kurzlebige Sperre, um diesen Eintrag neu zu generieren. Andere gleichzeitige Anfragen für denselben Eintrag bedienen weiterhin den vorhandenen lokalen Wert, anstatt ihn selbst zu regenerieren, was die Anzahl der Regenerierungsstempel und die redundante Backend-Last reduziert.

Auswirkung

Detaillierte Konfigurationsoptionen finden Sie unter: