[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 Netzwerk-Traffic zwischen dem Remote-Cache-Speicher (Redis oder Valkey) und der Commerce-Anwendung, indem eine lokale Cache-Ebene auf jedem Web-Knoten hinzugefügt wird. Eine standardmäßige Commerce-Instanz überträgt etwa 300 KB pro Anfrage, und der Traffic kann in einigen Situationen schnell auf über 1.000 Anfragen wachsen.
Beim L2-Caching speichert jeder Web-Knoten häufig aufgerufene Daten lokal und verwendet den Remote-Cache für zwei Zwecke:
- Überprüfen der Cache-Datenversion, um sicherzustellen, dass der neueste Cache lokal gespeichert wird
- Übertragen aktualisierter Cache-Daten vom Remote-Speicher auf den lokalen Computer
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-Computer abgerufen.
Es stehen zwei L2-Cache-Implementierungen zur Verfügung:
Cm_Cache_Backend_File für lokalen SpeicherKonfiguration des alten L2-Cache (RemoteSynchronizedCache)
Die Anweisungen zur Cache-Konfiguration hängen von Ihrem Bereitstellungstyp ab:
-
Für Adobe Commerce in Cloud konfigurieren Sie den L2-Cache, indem Sie die Variable “
REDIS_BACKEND” oder "VALKEY_BACKENDdeploy“ in.magento.env.yamlfestlegen. Konfigurationsbeispiele finden Sie Konfigurieren des L2Cache). -
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:
-
backendist die L2-Cache-Implementierung. -
backend_optionsist die L2-Cache-Konfiguration.remote_backendist die Remote-Cache-Implementierung: Redis oder MySQL.remote_backend_optionsist die Remote-Cache-Konfiguration.local_backendist die lokale Cache-Implementierung:Cm_Cache_Backend_Filelocal_backend_optionsist die lokale Cache-Konfiguration.cache_dirist eine Datei-Cache-spezifische Option für das Verzeichnis, in dem der lokale Cache gespeichert ist.
Für Adobe Commerce empfiehlt Adobe die Verwendung von Redis für das Remote-Caching (\Magento\Framework\Cache\Backend\Redis) und Cm_Cache_Backend_File für das lokale Caching von Daten im gemeinsamen Speicher mit: 'local_backend_options' => ['cache_dir' => '/dev/shm/']
Adobe empfiehlt die Verwendung der cache preload-Funktion, da sie den Druck auf Redis drastisch verringert. Vergessen Sie nicht, das Suffix “:hash” für Vorabladeschlüssel hinzuzufü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.
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 Händler Hunderte von Schlüsseln im Block/Config-Cache haben, sodass selbst eine kleine Zeitüberschreitung bei der Suche nach einer Sperre Sekunden kosten kann.
'use_stale_cache' => true zur Konfiguration der obersten Ebene des L2-Cache-Frontends hinzu.Adobe empfiehlt, die Option use_stale_cache nur für Cache-Typen zu aktivieren, die am meisten davon profitieren, darunter:
block_htmlconfig_integration_apiconfig_integrationfull_pagelayoutreflectiontranslate
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:
'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']
],
],
Moderne Symfony L2-Cache-Implementierung
Verwenden Sie in Commerce ab Version 2.4.9 die Symfony Cache-basierte L2-Cache-Implementierung (symfony_l2-Backend) anstelle des alten L2-Cache. Der Symfony L2-Cache bietet eine moderne, PSR-6-konforme Caching-Implementierung mit deutlichen Leistungsverbesserungen gegenüber herkömmlichen RemoteSynchronizedCache.
symfony_l2 verwenden zu können. Commerce On-Premises finden Sie unter Einrichten von Valkey. Informationen zu Commerce on Cloud finden Sie unter Einrichten von Valkeysymfony_l2. Wenn Sie eine Version verwenden, die symfony_l2 unterstützt, müssen Sie Valkey zum Caching verwenden. Siehe Systemanforderungen fürVorteile des Symfony L2-Cache
- Moderne Architektur: Basierend auf Symfony-Cache-Komponenten (PSR-6-kompatibel)
- Better Performance: Native Unterstützung für Igbinary-Serialisierung, Gzip-Komprimierung und Lua-Skripte
- Persistente Verbindungen: Reduziert den Verbindungsaufwand im Valley durch Verbindungspools
- Schlüssel vorladen: Unterstützt das Vorausfüllen von Cache-Schlüsseln für kritische Daten
- Unterstützung für veralteten Cache: Vollständige Kompatibilität mit der
use_stale_cacheOption - Vereinfachte Konfiguration: Cleaner Backend-Typnamen (
valkey,file)
Konfigurationsbeispiel mit Symfony L2-Cache
ece-tools) die Cache-Konfiguration automatisch. app/etc/env.php nicht direkt bearbeiten - manuelle Änderungen werden durch die Bereitstellung überschrieben. Informationen zur Cloud-Konfiguration finden Sie Konfigurieren des Symfony L2-Cache.Verwenden Sie den vereinfachten symfony_l2-Backend-Typ für den L2-Cache:
'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',
'persistent_id' => 'magento_l2_default',
'timeout' => '2.5',
'read_timeout' => '2.0',
'use_lua' => '1',
'preload_keys' => [
'prefix_EAV_ENTITY_TYPES:hash',
'prefix_GLOBAL_PLUGIN_LIST:hash',
'prefix_DB_IS_UP_TO_DATE:hash',
'prefix_SYSTEM_DEFAULT:hash',
],
],
// 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
Konfigurieren von separaten Frontends für die Unterstützung veralteter Caches:
'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',
'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',
'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
remote_backend'valkey'valkey oder file. Verwenden Sie valkey für den L2-Cache.remote_backend_options[]local_backend'file'file oder apculocal_backend_options[]cleanup_percentage95use_stale_cachefalseremote_backend-Option akzeptiert außerdem den Wert redis. Redis ist jedoch kein offiziell unterstützter Cache-Service für Adobe Commerce 2.4.9 und höher. Adobe empfiehlt, symfony_l2 nur mit valkey zu konfigurieren. Siehe Systemanforderungen für unterstützte Cache-Services nach Version.Verbesserte Symfony L2-Cache-Leistung und Zuverlässigkeit
symfony_l2 und sind mit dem Patch ACP2E-5132 verfügbar. Unter Cloud-Patches für Commerce finden Sie die neuesten Patch-Versionshinweise.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
Optimiertes Symfony L2-Cache-Verhalten für Valkey-gestützte Bereitstellungen durch Eliminierung redundanter Dateisystem-Tag-Index-Schreibvorgänge. Cache-Tags werden jetzt ausschließlich in Valkey gespeichert, wodurch das Symfony L2-Cache-Verhalten an der Legacy-Cache-Implementierung ausgerichtet wird. Dies reduziert unnötige Datenträger-E/A, verbessert die Cache-Schreibleistung und verhindert das Wachstum des var/cache/symfony/tags/.
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.
Feste veraltete Tag-Mitgliedschaften nach dem erneuten Taggen
Wenn Sie einen Cache-Eintrag erneut taggen, ist er möglicherweise mit Tags verknüpft, 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 - Redundantes Remote-Schreiben wird bei unverändertem Speichern behoben
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.
Feste L1-Größenbasierte Entfernung (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.
Regenerierungssperre für veralteten Cache hinzugefügt
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
- Beseitigt redundante Dateisystem-Tag-Indexschreibvorgänge für Valkey-unterstützte Symfony L2-Cache-Bereitstellungen, reduziert den Festplatten-E/A und verhindert unnötiges Wachstum des
var/cache/symfony/tags/. - Stellt sicher, dass dateibasierte Cache-Bereitstellungen konsistent die konfigurierten
cache_dirfür den lokalen Tag-Index verwenden, während das Verhalten bei der Cache-Invalidierung erhalten bleibt. - Verhindert die falsche Cache-Invalidierung, die durch veraltete Tag-Mitgliedschaften verursacht wird, die nach dem Retagging zurückbleiben.
- Reduziert unnötige Remote-Schreibvorgänge für unveränderte Cache-Speichervorgänge und verringert so die Netzwerk- und Backend-Last.
- Stellt sicher, dass Trigger mit L1-Cache-Entfernung zuverlässig den konfigurierten
cleanup_percentageerreichen. - Reduziert die Anzahl von Regenerierungsstempeln für
use_stale_cacheEinträge, indem ein einzelner Regenerator pro Schlüssel ausgewählt wird, anstatt dass jede gleichzeitige Anforderung ihn neu erstellt.
Detaillierte Konfigurationsoptionen finden Sie unter: