[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:

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.

In Adobe Commerce stehen zwei L2-Cache-Implementierungen zur Verfügung:

Der Symfony L2-Cache ist die empfohlene Implementierung für Adobe Commerce 2.4.9 und neuere Versionen. Es bietet eine moderne, PSR-6-konforme Caching-Implementierung mit erheblichen Leistungsverbesserungen im Vergleich zu herkömmlichen RemoteSynchronizedCache.

Konfiguration des alten L2-Cache (RemoteSynchronizedCache)

Die Konfigurationsanweisungen für den alten L2-Cache gelten für ältere Versionen von Adobe Commerce. Wenn Sie Adobe Commerce Version 2.4.9 oder höher verwenden, verwenden Sie Valkey mit der Modern Symfony L2 Cache-Implementierung.

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 unterstützen, 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. Die in diesem Abschnitt beschriebenen empfohlenen Cache-Typen und Kompromisse gelten sowohl für die veralteten 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 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.

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 alte 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']
    ],
],

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.

Vorteile des Symfony L2-Cache

Migration von RemoteSynchronizedCache zu Symfony L2

Wenn Sie ein Upgrade einer lokalen Installation vom alten 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.

'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

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.

Veraltete Tag-Mitgliedschaftskorrektur nach dem Retagging

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 - 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: