DokumentationCommerceImplementierungs-Playbook

[Commerce in Cloud Manager]{class="badge informative" title="Gilt nur für Adobe Commerce in Cloud-Projekten."}

Best Practices für die Konfiguration des Valley- und Redis-Service

Letzte Aktualisierung: 16. September 2026

Erstellt für:

  • Fortgeschritten
  • Admin
  • Entwicklerin/Entwickler

Verwenden Sie diese Empfehlungen beim Konfigurieren von Redis oder Valkey für Adobe Commerce-Anwendungscache, Sitzungsspeicher und L2-Cache für Adobe Commerce in Cloud-Bereitstellungen.

  • Konfigurieren des L2-Cache, einschließlich Symfony L2-Cache
  • Aktivieren Sie in Cloud Pro-Umgebungen die schreibgeschützte Replikatverbindung (Slave). Diese Funktion ist nicht in Starter-Umgebungen verfügbar.
  • Schlüssel vorausfüllen
  • Veralteten Cache aktivieren
  • Cache und Sitzung trennen
  • Komprimieren des Cache
  • Konfigurationsbeispiele überprüfen
NOTE
Stellen Sie sicher, dass Sie die neueste Version des ece-tools verwenden. Falls nicht, aktualisieren Sie auf die neueste Version. Sie können die in Ihrer lokalen Umgebung installierte Version mithilfe des composer show magento/ece-tools CLI-Befehls überprüfen.

L2-Cache konfigurieren

Konfigurieren Sie den L2-Cache, indem Sie die Bereitstellungsvariable VALKEY_BACKEND oder REDIS_BACKEND in der Konfigurationsdatei .magento.env.yaml festlegen.

IMPORTANT
Die Redis-Konfigurationsbeispiele auf dieser Seite gelten nur für unterstützte Adobe Commerce-Versionen, die Redis verwenden. Siehe Systemanforderungen für unterstützte Cache-Services nach Version. Redis-Cache wird für Adobe Commerce 2.4.9 oder für Patch-Versionen nach 2.4.5-p16, 2.4.6-p14, 2.4.7-p9 und 2.4.8-p4 nicht unterstützt. Verwenden Sie Valley für die Cache-Konfiguration, bei der Redis nicht unterstützt wird. Siehe Systemanforderungen für unterstützte Cache-Services nach Version.

Durch Festlegen von VALKEY_BACKEND oder REDIS_BACKEND wird das L2-Cache-Backend konfiguriert, es wird jedoch nicht bestimmt, ob Adobe Commerce Redis oder Valkey als Remote-Cache-Service verwendet. Der zugewiesene Klassenwert (z. B. \Magento\Framework\Cache\Backend\Redis oder symfony_l2) wählt den Service ebenfalls nicht aus. Adobe Commerce verwendet den in Ihrer Umgebung verfügbaren -Service - Redis oder Valkey -, und Redis hat Priorität, wenn beide verfügbar sind. Beispielsweise verwendet VALKEY_BACKEND: '\Magento\Framework\Cache\Backend\Redis' Redis, wenn verfügbar, und kehrt nur dann zu Valkey zurück, wenn Redis nicht verfügbar ist.

Verwenden von VALKEY_BACKEND

Verwenden Sie für Valkey mit der RemoteSynchronizedCache Implementierung Folgendes:

code language-yaml 
stage:
  deploy:
    VALKEY_BACKEND: '\Magento\Framework\Cache\Backend\RemoteSynchronizedCache'

Für Valkey mit der Symfony L2 Cache-Implementierung siehe Konfigurieren des Symfony L2 Cache.

Verwenden von REDIS_BACKEND

Verwenden Sie für Redis:

code language-yaml 
stage:
  deploy:
    REDIS_BACKEND: '\Magento\Framework\Cache\Backend\RemoteSynchronizedCache'

Weitere Informationen zur Umgebungskonfiguration finden Sie unter REDIS_BACKEND im Handbuch zu Commerce in Cloud-Infrastrukturen.

Konfigurieren des Symfony L2-Cache

Adobe Commerce 2.4.9 und höher unterstützt das symfony_l2-Cache-Backend. Das symfony_l2-Backend ist die Cache-Implementierung, die Adobe Commerce verwendet, um das L1- und L2-Cache-Verhalten zu verwalten. Redis oder Valley als Remote-Cache-Service wird nicht ersetzt.

IMPORTANT
Konfigurieren Sie symfony_l2 nicht manuell in app/etc/env.php als persistente Konfiguration für Adobe Commerce in der Cloud-Infrastruktur. Die Bereitstellung kann manuelle env.php überschreiben. Wenn ece-tools nicht symfony_l2 gilt, kann Commerce auf den dateibasierten Cache zurückgreifen. Dieser Fallback kann die Festplatten-E/A erhöhen, den Overhead bei der Dateisystemreplikation in Umgebungen mit mehreren Knoten erhöhen und die Leistung beeinträchtigen.

Um symfony_l2 Cache für Adobe Commerce 2.4.9 zu verwenden, führen Sie die folgenden Schritte aus:

  • Stellen Sie sicher, dass das Cloud-Projekt das ECE-Tools-Paket v2002.2.12 oder höher verwendet.

  • Legen Sie die Bereitstellungsvariable in der .magento.env.yaml fest: VALKEY_BACKEND=symfony_l2.

    code language-yaml 
    stage:
  deploy:
    VALKEY_BACKEND: symfony_l2

Wenn Sie VALKEY_BACKEND auf symfony_l2 setzen, wird die vollständige L2-Cache-Konfiguration aus Ihren Valkey-Service-Details erstellt, einschließlich default- und stale_cache_enabled-Frontends, mit zwischenspeicherbaren Typen wie layout, block_html, full_page und translate, die dem veralteten Frontend zugeordnet sind. Die Definition von CACHE_CONFIGURATION ist optional und nur erforderlich, wenn Sie bestimmte Backend-Optionen anpassen möchten.

NOTE
In diesem Abschnitt werden der Anwendungscache und die Sitzungs-Backends von Commerce behandelt. Das HTTP-Caching ganzer Seiten, wie Fastly oder Varnish, ist eine separate Caching-Ebene und wird unabhängig konfiguriert. Änderungen am Anwendungs-Cache-Backend ersetzen oder konfigurieren nicht den HTTP-Vollseiten-Cache.

Diese Empfehlungen betreffen Folgendes:

  • Einen unterstützten Cache-Service auswählen
  • Replikatverbindung aktivieren
  • Separate Cache- und Sitzungsinstanzen
  • Cache-Komprimierung konfigurieren
  • Asynchrone Freigabe aktivieren
  • Multithread-E/A aktivieren
  • Client-Zeitüberschreitungen und erneute Versuche erhöhen
  • Konfigurieren des L2-Cache, einschließlich Vorabladeschlüssel, veralteten Cache und Symfony L2-Cache
  • Konfigurationsbeispiele überprüfen

Einen unterstützten Cache-Service auswählen

Adobe Commerce-Version
Empfohlener Cache-Service
L2-Cache-Implementierung
2.4.8 und früher, wenn von der exakten Version unterstützt
Redis oder Valkey
RemoteSynchronizedCache
2.4.9 und höher
Tal
symfony_l2

Redis wird für die Cache-Konfiguration in Adobe Commerce 2.4.9 und in Patch-Versionen, in denen die Systemanforderungen Valkey spezifizieren, nicht unterstützt. Überprüfen Sie immer die genaue Commerce-Version, die Patch-Ebene und die Service-Version in Cache-Backend-Optionen und Speicherreferenz und Systemanforderungen.

Die folgenden Beispiele zeigen den Konfigurations-Code in der .magento.env.yaml:

Verwenden von VALKEY_BACKEND
code language-yaml 
stage:
  deploy:
    VALKEY_BACKEND: '\Magento\Framework\Cache\Backend\RemoteSynchronizedCache'
    CACHE_CONFIGURATION:
      _merge: true
      frontend:
        default:
          backend_options:
            cleanup_percentage: 90
Verwenden von REDIS_BACKEND
code language-yaml 
stage:
  deploy:
    REDIS_BACKEND: '\Magento\Framework\Cache\Backend\RemoteSynchronizedCache'
    CACHE_CONFIGURATION:
      _merge: true
      frontend:
        default:
          backend_options:
            cleanup_percentage: 90

Die Cache-Anforderungen variieren je nach Projektkonfiguration und benutzerdefiniertem Code von Drittanbietern. Größe des L2-Cache-Speichers, damit der Cache ohne häufige Schwellenwerttreffer arbeiten kann.

Idealerweise bleibt die Speicherauslastung des L2-Cache unter dem Schwellenwert, um eine häufige Speicherbereinigung zu vermeiden.

Sie können die Speicherauslastung des L2-Cache auf jedem Knoten des Clusters überprüfen, indem Sie den folgenden CLI-Befehl ausführen und die /dev/shm Zeile überprüfen.

df -h /dev/shm

Die Nutzung variiert je nach Knoten, konvergiert jedoch zu einem ähnlichen Wert.

Schreibgeschützte Replikatverbindung aktivieren enable-slave-connection

Aktivieren Sie die schreibgeschützte Replikatverbindung in der .magento.env.yaml. Auf diese Weise kann Adobe Commerce eine zusätzliche Cache-Verbindung für Lesevorgänge verwenden, während weiterhin der primäre Endpunkt für Schreibvorgänge verwendet wird. Durch diese Konfiguration kann die Leselast auf dem primären Cache-Service reduziert und der Lesetraffic effektiver verteilt werden.

IMPORTANT
Im Gegensatz zu VALKEY_BACKEND und REDIS_BACKEND sind die VALKEY_USE_SLAVE_CONNECTION- und REDIS_USE_SLAVE_CONNECTION-Variablen an einen bestimmten Service gebunden. Legen Sie die Variable fest, die dem in Ihrer Umgebung verfügbaren Cache-Service entspricht. Verwenden Sie nicht unbedingt denselben Service, der durch die Variable *_BACKEND wird, die Sie für die Konfiguration des L2-Cache verwendet haben.
NOTE
Ob eine Replikatverbindung verfügbar ist, hängt von der Topologie Ihres Projekts (z. B. Single-Node- versus Split- oder HA-Architektur) und von der ece-tools Version ab. Bevor Sie diese Einstellung verwenden, überprüfen Sie, ob eine Replikatbeziehung für Ihren Dienst vorhanden ist, indem Sie echo $MAGENTO_CLOUD_RELATIONSHIPS | base64 -d | json_pp ausführen und nach einem USE_SLAVE_CONNECTION Eintrag suchen. Um zu bestätigen, ob Ihre Topologie einen Replikat-Endpunkt bereitstellt, aktualisieren Sie ece-tools und stellen Sie erneut bereit oder wenden Sie sich an den Adobe Commerce-Support, wenn kein USE_SLAVE_CONNECTION vorhanden ist.
USE VALKEY_USE_SLAVE_CONNECTION

Verwenden Sie für Valley Folgendes:

code language-yaml 
stage:
  deploy:
    VALKEY_USE_SLAVE_CONNECTION: true

Details zur Konfiguration von Umgebungsvariablen finden Sie unter VALKEY USE SLAVE_CONNECTION im Handbuch zu Commerce in Cloud Infrastructure.

Using REDIS_USE_SLAVE_CONNECTION

Verwenden Sie für Redis:

code language-yaml 
stage:
  deploy:
    REDIS_USE_SLAVE_CONNECTION: true

Details zur Konfiguration von Umgebungsvariablen finden Sie unter REDIS USE SLAVE_CONNECTION im Handbuch zu Commerce in Cloud Infrastructure.

Schlüssel vorausfüllen

Adobe Commerce lädt normalerweise Cache-Einträge aus Redis oder Valkey einzeln. Mit der Vorabladefunktion können Sie eine Liste häufig verwendeter Schlüssel bereitstellen, die Adobe Commerce bei dem ersten Zugriff während einer Anfrage in einer einzigen Pipeline abruft. Adobe Commerce speichert die abgerufenen Werte dann für den Rest der Anfrage im PHP-Speicher, was die wiederholten Roundtrips zu Redis oder Valkey reduziert und die Bootstrap-Performance der Anfragen für diese Schlüssel verbessern kann.

Häufig verwendete Tasten können durch die Überwachung aktiver Befehle auf Redis oder Valley identifiziert werden:

Schlüssel mit VALKEY_BACKEND vorausfüllen

Die Vorabladeschlüssel werden in der .magento.env.yaml-Konfigurationsdatei konfiguriert.

code language-yaml 
stage:
  deploy:
    VALKEY_BACKEND: '\Magento\Framework\Cache\Backend\RemoteSynchronizedCache'
    CACHE_CONFIGURATION:
      _merge: true
      frontend:
        default:
          id_prefix: '061_' # Prefix for keys to be preloaded, it can be any random string
          backend_options:
            preload_keys: # List the keys to be preloaded
              - '061_EAV_ENTITY_TYPES:hash' # The key name must start with the id_prefix set above
              - '061_GLOBAL_PLUGIN_LIST:hash'
              - '061_DB_IS_UP_TO_DATE:hash'
              - '061_SYSTEM_DEFAULT:hash'

Um die Schlüssel aufzulisten, führen Sie den folgenden Befehl aus:

code language-terminal 
valkey-cli -p 6370 -n 1 MONITOR > /tmp/list.keys

Drücken Sie nach 10 Sekunden Ctrl+C. Führen Sie dann den folgenden Befehl aus:

code language-terminal 
cat /tmp/list.keys | grep "HGET" | awk '{print $5}' | sort | uniq -c | sort -nr | head -n 50

In diesem Protokoll werden die Schlüssel aufgelistet, die Sie vorab laden können. Um den Inhalt eines Schlüssels anzuzeigen, führen Sie den folgenden Befehl aus:

code language-terminal 
valkey-cli -p 6370 -n 1 hgetall "<key_name>"
Schlüssel mit REDIS_BACKEND vorausfüllen

Die Vorabladeschlüssel werden in der .magento.env.yaml-Konfigurationsdatei konfiguriert.

code language-yaml 
stage:
  deploy:
    REDIS_BACKEND: '\Magento\Framework\Cache\Backend\RemoteSynchronizedCache'
    CACHE_CONFIGURATION:
      _merge: true
      frontend:
        default:
          id_prefix: '061_' # Prefix for keys to be preloaded, it can be any random string
          backend_options:
            preload_keys: # List the keys to be preloaded
              - '061_EAV_ENTITY_TYPES:hash' # The key name must start with the id_prefix set above
              - '061_GLOBAL_PLUGIN_LIST:hash'
              - '061_DB_IS_UP_TO_DATE:hash'
              - '061_SYSTEM_DEFAULT:hash'

Um die Schlüssel aufzulisten, führen Sie den folgenden Befehl aus:

code language-terminal 
redis-cli -p 6370 -n 1 MONITOR > /tmp/list.keys

Drücken Sie nach 10 Sekunden Ctrl+C. Führen Sie dann den folgenden Befehl aus:

code language-terminal 
cat /tmp/list.keys | grep "HGET" | awk '{print $5}' | sort | uniq -c | sort -nr | head -n 50

In diesem Protokoll werden die Schlüssel aufgelistet, die Sie vorab laden können. Um den Inhalt eines Schlüssels anzuzeigen, führen Sie den folgenden Befehl aus:

code language-terminal 
redis-cli -p 6370 -n 1 hgetall "<key_name>"

Veralteten Cache aktivieren

Veralteter Cache ist eine L2-Cache-Funktion, die sowohl von der RemoteSynchronizedCache- als auch von der symfony_l2-Implementierung unterstützt wird. Wenn diese Option aktiviert ist, kann Adobe Commerce einen vorhandenen lokalen Cache-Wert aus /dev/shm bereitstellen, während eine andere Anfrage bereits denselben Eintrag neu generiert, anstatt jede gleichzeitige Anfrage warten zu lassen. Dadurch werden Cache-Stampedes und Sperrkonflikte bei der Neuerstellung teurer Cache-Einträge reduziert.

Funktionsweise

Der L2-Cache verwaltet zwei Kopien jedes Cache-Eintrags: eine lokale Kopie in /dev/shm und eine Remote-Kopie in Redis oder Valkey. Wenn die Remote Copy nicht verfügbar ist und bereits eine Regenerierungssperre für diesen Schlüssel vorhanden ist, können gleichzeitige -Anfragen den vorherigen lokalen Wert empfangen, anstatt zu warten, bis der neue Wert geschrieben wird.

Um den veralteten Cache zu aktivieren, konfigurieren Sie ihn in der .magento.env.yaml.

Konfigurieren des veralteten Cache mit VALKEY_BACKEND

Für Valley:

code language-yaml 
stage:
  deploy:
    VALKEY_BACKEND: '\Magento\Framework\Cache\Backend\RemoteSynchronizedCache'
    CACHE_CONFIGURATION:
      _merge: true
      frontend:
        default:
          backend_options:
            use_stale_cache: true
Konfigurieren des veralteten Cache mit REDIS_BACKEND

Für Redis:

code language-yaml 
stage:
  deploy:
    REDIS_BACKEND: '\Magento\Framework\Cache\Backend\RemoteSynchronizedCache'
    CACHE_CONFIGURATION:
      _merge: true
      frontend:
        default:
          backend_options:
            use_stale_cache: true
WARNING
Wenn dies zu unerwartetem Verhalten in Ihren Anpassungen führt, lassen Sie den veralteten Cache im default-Frontend deaktiviert und aktivieren Sie ihn nur für ausgewählte Cache-Typen, wie es häufig lokal) ​.

Veralteter Cache pro Cache-Typ einzeln aktivieren

Sie können veralteten Cache nur für ausgewählte Cache-Typen aktivieren, indem Sie ein dediziertes Cache-Frontend in .magento.env.yaml definieren und die ausgewählten Cache-Typen ihm zuordnen.

Um ordnungsgemäß zu funktionieren, muss das benutzerdefinierte Frontend als vollständiges Frontend unter CACHE_CONFIGURATION.frontend definiert werden. Es reicht nicht aus, nur use_stale_cache: true für einen neuen Frontend-Namen zu definieren.

Beispielkonfigurationen

Konfigurieren des veralteten Cache mit VALKEY_BACKEND

Für Valley:

code language-yaml 
stage:
  deploy:
    VALKEY_BACKEND: '\Magento\Framework\Cache\Backend\RemoteSynchronizedCache'
    CACHE_CONFIGURATION:
      _merge: true
      frontend:
        default: # In this frontend, we keep stale cache set to false.
          id_prefix: '001_'
          backend_options:
            use_stale_cache: false

        # Now, create a new frontend called 'stale_cache_enabled'.
        # It must contain the same backend connection settings as the frontend 'default':

        stale_cache_enabled:
          id_prefix: '001_'
          backend: '\Magento\Framework\Cache\Backend\RemoteSynchronizedCache'
          backend_options:
            remote_backend: '\Magento\Framework\Cache\Backend\Valkey'
            remote_backend_options:
              server: localhost
              port: 6370 # Use the same port used by the frontend 'default' in env.php
              database: 1
              load_from_slave:
                server: localhost
                port: 26370 # Use the same port used by the frontend 'default' in env.php
              retry_reads_on_master: 1
              read_timeout: 10
            local_backend: 'Cm_Cache_Backend_File'
            local_backend_options:
              cache_dir: /dev/shm/
            use_stale_cache: true # stale cache here is enabled

      # Now select which cache types you want to enable (stale_cache_enabled), or disable (default)

      type:
        default:
          frontend: default
        layout:
          frontend: stale_cache_enabled
        reflection:
          frontend: stale_cache_enabled
        config_integration:
          frontend: stale_cache_enabled
        config_integration_api:
          frontend: stale_cache_enabled
        translate:
          frontend: stale_cache_enabled
        # add other cache types as needed...
Konfigurieren des veralteten Cache mit REDIS_BACKEND

Für Redis:

code language-yaml 
stage:
  deploy:
    REDIS_BACKEND: '\Magento\Framework\Cache\Backend\RemoteSynchronizedCache'
    CACHE_CONFIGURATION:
      _merge: true
      frontend:
        default: # In this frontend, we keep stale cache set to false.
          id_prefix: '001_'
          backend_options:
            use_stale_cache: false

        # Now, create a new frontend called 'stale_cache_enabled'.
        # It must contain the same backend connection settings as the frontend 'default':

        stale_cache_enabled:
          id_prefix: '001_'
          backend: '\Magento\Framework\Cache\Backend\RemoteSynchronizedCache'
          backend_options:
            remote_backend: '\Magento\Framework\Cache\Backend\Redis'
            remote_backend_options:
              server: localhost
              port: 6370 # Use the same port used by the frontend 'default' in env.php
              database: 1
              load_from_slave:
                server: localhost
                port: 26370 # Use the same port used by the frontend 'default' in env.php
              retry_reads_on_master: 1
              read_timeout: 10
            local_backend: 'Cm_Cache_Backend_File'
            local_backend_options:
              cache_dir: /dev/shm/
            use_stale_cache: true # stale cache here is enabled

      # Now select which cache types you want to enable (stale_cache_enabled), or disable (default)

      type:
        default:
          frontend: default
        layout:
          frontend: stale_cache_enabled
        reflection:
          frontend: stale_cache_enabled
        config_integration:
          frontend: stale_cache_enabled
        config_integration_api:
          frontend: stale_cache_enabled
        translate:
          frontend: stale_cache_enabled
        # add other cache types as needed...
NOTE
Wenn das Quell-Frontend mit zusätzlichen Backend-Optionen wie Komprimierung, erneuten Versuchen, Vorabladen von Schlüsseln oder anderen Optimierungswerten konfiguriert ist, kopieren Sie diese Optionen in stale_cache_enabled, damit das neue Frontend dasselbe Verhalten beibehält.

Separate Cache- und Sitzungsinstanzen

Cache- und Sitzungskonfiguration sind unabhängig. SESSION_CONFIGURATION beeinflusst das Cache-Verhalten nicht, unabhängig davon, welches Cache-Backend oder welche L2-Cache-Implementierung Sie verwenden. Wenn Sie den Cache von den Sitzungen trennen, können Sie diese unabhängig verwalten. Es verringert Konflikte zwischen Cache- und Sitzungs-Traffic, verhindert, dass Cache-bedingter Druck sich auf Sitzungen auswirkt, und ermöglicht die Dimensionierung und Abstimmung jeder Redis- oder Valley-Instanz auf ihre eigene Arbeitslast.

IMPORTANT
Um eine dedizierte Sitzungsinstanz für Produktions- und Staging-Umgebungen bereitzustellen, müssen Sie ein Adobe Commerce-Support-Ticket mit Ihren aktualisierten .magento/services.yaml- und .magento.app.yaml wie in Schritt 3 unten beschrieben senden.

Gehen Sie wie folgt vor, um eine dedizierte Instanz für Sitzungen bereitzustellen:

Valkey

  1. Aktualisieren Sie die .magento/services.yaml Konfigurationsdatei und ersetzen Sie <version> durch die verwendeten Service-Versionen. Siehe Systemanforderungen für unterstützte Service-Versionen nach Version.

    code language-yaml 
    mysql:
  type: mysql:<version>
  disk: 35000

valkey:
  type: valkey:<version>

valkey-session: # This is for the new Valkey instance
  type: valkey:<version>

search:
  type: elasticsearch:<version>
  disk: 5000

rabbitmq:
  type: rabbitmq:<version>
  disk: 2048

  2. Aktualisieren Sie die .magento.app.yaml Konfigurationsdatei.

    code language-yaml 
    relationships:
  database: "mysql:mysql"
  valkey: "valkey:valkey"
  valkey-session: "valkey-session:valkey"   # Relationship of the new Valkey instance
  search: "search:elasticsearch"
  rabbitmq: "rabbitmq:rabbitmq"

  3. Fordern Sie eine neue Valley-Instanz an, die Sitzungen zu Produktions- und Staging-Umgebungen gewidmet ist.

    Senden Sie ein Adobe Commerce-Support-Ticket. Schließen Sie die aktualisierten .magento/services.yaml und .magento.app.yaml Konfigurationsdateien ein.

    Dieses Update verursacht keine Ausfallzeiten, erfordert jedoch eine Bereitstellung, um den neuen Service zu aktivieren.

  4. Stellen Sie sicher, dass die neue Instanz ausgeführt wird, und notieren Sie die Portnummer.

    code language-shell 
    echo $MAGENTO_CLOUD_RELATIONSHIPS | base64 -d | json_pp

  5. Fügen Sie die Portnummer zur .magento.env.yaml hinzu.

    note important
    IMPORTANT
    Konfigurieren Sie den Valkey-Sitzungs-Port nur, wenn ece-tools ihn nicht automatisch aus der Definition des MAGENTO_CLOUD_RELATIONSHIPS Valkey-Sitzungs-Service erkennen kann.
    note
    NOTE
    Für optimale Leistung disable_locking auf 1 gesetzt. In seltenen Fällen, in denen Wettlaufsituationen aufgrund einer hohen Aktivität von gleichzeitigen Sitzungen auftreten, aktivieren Sie die Sperrung, indem Sie 0 festlegen.
    code language-yaml 
    SESSION_CONFIGURATION:
  _merge: true
  redis: # keep 'redis' even if you are using Valkey.
    timeout: 5
    disable_locking: 1
    bot_first_lifetime: 60
    bot_lifetime: 7200
    max_lifetime: 2592000
    min_lifetime: 60

  6. Entfernen Sie Sitzungen aus der Standarddatenbank (db 0) auf der Valkey-Cache-Instanz.

    code language-terminal 
    valkey-cli -h 127.0.0.1 -p 6370 -n 0 FLUSHDB
Redis

  1. Aktualisieren Sie die .magento/services.yaml Konfigurationsdatei und ersetzen Sie <version> durch die verwendeten Service-Versionen.

    code language-yaml 
    mysql:
  type: mysql:<version>
  disk: 35000

redis:
  type: redis:<version>

redis-session: # This is for the new Redis instance
  type: redis:<version>

search:
  type: elasticsearch:<version>
  disk: 5000

rabbitmq:
  type: rabbitmq:<version>
  disk: 2048

  2. Aktualisieren Sie die .magento.app.yaml Konfigurationsdatei.

    code language-yaml 
    relationships:
  database: "mysql:mysql"
  redis: "redis:redis"
  redis-session: "redis-session:redis"   # Relationship of the new Redis instance
  search: "search:elasticsearch"
  rabbitmq: "rabbitmq:rabbitmq"

  3. Fordern Sie eine neue Redis-Instanz für Sitzungen in Produktions- und Staging-Umgebungen an.

    Senden Sie ein Adobe Commerce-Support-Ticket. Schließen Sie die aktualisierten .magento/services.yaml und .magento.app.yaml Konfigurationsdateien ein.

    Dieses Update verursacht keine Ausfallzeiten, erfordert jedoch eine Bereitstellung, um den neuen Service zu aktivieren.

  4. Stellen Sie sicher, dass die neue Instanz ausgeführt wird, und notieren Sie die Portnummer.

    code language-shell 
    echo $MAGENTO_CLOUD_RELATIONSHIPS | base64 -d | json_pp

  5. Fügen Sie die Portnummer zur .magento.env.yaml hinzu.

    note important
    IMPORTANT
    Konfigurieren Sie den Redis-Sitzungs-Port nur, wenn ece-tools ihn nicht automatisch aus der Definition des MAGENTO_CLOUD_RELATIONSHIPS Redis-Sitzungs-Service erkennen kann.
    note
    NOTE
    Für optimale Leistung disable_locking auf 1 gesetzt. In seltenen Fällen, in denen Wettlaufsituationen aufgrund einer hohen Aktivität von gleichzeitigen Sitzungen auftreten, aktivieren Sie die Sperrung, indem Sie 0 festlegen.
    code language-yaml 
    SESSION_CONFIGURATION:
  _merge: true
  redis:
    timeout: 5
    disable_locking: 1
    bot_first_lifetime: 60
    bot_lifetime: 7200
    max_lifetime: 2592000
    min_lifetime: 60

  6. Entfernen Sie Sitzungen aus der Standarddatenbank (db 0) auf der Redis-Cache-Instanz.

    code language-terminal 
    redis-cli -h 127.0.0.1 -p 6370 -n 0 FLUSHDB

Cache-Komprimierung

Wenn Sie mehr als 6 GB Redis- oder Valkey-maxmemory verwenden, können Sie die Cache-Komprimierung aktivieren, um den von Schlüsseln belegten Speicherplatz zu reduzieren. Beachten Sie, dass diese Einstellung Client-seitige Leistung gegen Speichereinsparungen eintauscht. Wenn Sie über freie CPU-Kapazität verfügen, sollten Sie diese aktivieren. Siehe Verwenden von Redis für ​ oder Verwenden von Valkey für ​ im Konfigurationshandbuch.

stage:
  deploy:
    CACHE_CONFIGURATION:
      _merge: true
      frontend:
        default:
          backend_options:
            compress_data: 4              # 0-9
            compress_tags: 4              # 0-9
            compress_threshold: 20480     # don't compress files smaller than this value
            compression_lib: 'gzip'       # snappy and lzf for performance, gzip for high compression (~69%)

Asynchrone Freigabe aktivieren

Um lazyfree in der Adobe Commerce-Cloud-Infrastruktur zu aktivieren, reichen Sie ein Adobe Commerce-SupportTicket ein, in dem Sie darum bitten, die folgende Redis- oder Valkey-Konfiguration auf Ihre Umgebungen anzuwenden:

lazyfree-lazy-eviction yes
lazyfree-lazy-expire yes
lazyfree-lazy-server-del yes
replica-lazy-flush yes
lazyfree-lazy-user-del yes

Wenn lazyfree aktiviert ist, lädt Redis oder Valley die Speicherrückgewinnung auf Hintergrund-Threads aus, um Auslagerungen, Abläufe, serverinitiierte Löschvorgänge, Benutzerlöschvorgänge und Replikatdatensatzleerungen durchzuführen. Dies reduziert die Blockierung des Haupt-Threads und kann die Anfragelatenz verringern.

NOTE
Durch die Option lazyfree-lazy-user-del yes verhält sich der DEL-Befehl wie UNLINK, wodurch die Verknüpfung von Schlüsseln sofort aufgehoben wird und der Speicher asynchron freigegeben wird.
WARNING
Da die Freigabe im Hintergrund erfolgt, wird Speicher, der von gelöschten, abgelaufenen oder entfernten Schlüsseln verwendet wird, zugewiesen, bis die Arbeit von Hintergrund-Threads abgeschlossen ist. Wenn Ihre Redis- oder Valley-Instanz bereits unter hohem Speicherdruck steht, testen Sie sie vorsichtig und erwägen Sie zuerst, den Speicherdruck zu reduzieren. Deaktivieren Sie beispielsweise den Block-Cache für bestimmte Fälle und trennen Sie die Cache- und Sitzungs-Redis-Instanzen wie oben beschrieben.

Multithread-E/A aktivieren

Um das Redis-I/O-Threading in der Adobe Commerce-Cloud-Infrastruktur zu aktivieren, senden Sie ein Adobe Commerce Support-Ticket mit der unten stehenden Anfrage zur I/O-Threading-Konfiguration. Durch diese Konfiguration kann der Durchsatz verbessert werden, indem Socket-Lese- und -Schreibvorgänge sowie das Parsen von Befehlen vom Haupt-Thread ausgelagert werden, was zulasten einer höheren CPU-Nutzung geht. Validieren Sie unter Last und überwachen Sie Ihre Hosts.

Konfigurieren von I/O-Threads für Redis

Für Redis:

code language-text 
io-threads-do-reads yes
io-threads 8 # Choose a value lower than the number of CPU cores (check with nproc), and then tune under load.
Konfigurieren von I/O-Threads für Valkey

Für Valley:

code language-text 
io-threads-do-reads yes
io-threads 8 # choose a value lower than the number of CPU cores (check with nproc), then tune under load
NOTE
I/O-Threads parallelisieren nur Client-I/O und Parsing. Die Ausführung des Redis-Befehls erfolgt weiterhin in einem einzigen Thread.
WARNING
Die Aktivierung von I/O-Threads kann die Nutzung von CPU erhöhen und nützt nicht jeder Arbeitslast. Beginnen Sie mit einem konservativen Wert und Benchmark. Wenn die Latenz ansteigt oder CPU überlastet ist, reduzieren Sie io-threads oder deaktivieren Sie Lesevorgänge in I/O-Threads.

Client-Zeitüberschreitungen und erneute Versuche erhöhen

Erhöhen Sie die Toleranz des Redis- oder Valkey-Cache-Clients auf kurze Zeiträume der Sättigung, indem Sie die Backend-Optionen in .magento.env.yaml anpassen.

stage:
  deploy:
    CACHE_CONFIGURATION:
      _merge: true
      frontend:
        default:
          backend_options:
            connect_retries: 3 # Number of connection retries
            remote_backend_options:
              read_timeout: 10 # Timeout

Diese Einstellungen können unregelmäßige Verbindungs- und Lesezeitüberschreitungsfehler während kurzer Spitzen reduzieren, indem die Verbindungseinrichtung wiederholt wird und mehr Zeit für Antworten von Redis oder Valley bleibt.

NOTE
Diese Einstellungen können bei einer kurzen Überlastung helfen, aber sie beheben nicht die dauerhafte Überlastung.

L2-Cache konfigurieren

Konfigurieren Sie den L2-Cache, indem Sie die Bereitstellungsvariable VALKEY_BACKEND oder REDIS_BACKEND in der Konfigurationsdatei .magento.env.yaml festlegen.

Es gibt zwei L2-Cache-Implementierungen für Adobe Commerce in der Cloud-Infrastruktur.

  • RemoteSynchronizedCache verwendet Cm_Cache_Backend_File für den lokalen Speicher.
  • symfony_l2 ist PSR-6-kompatibel und unterstützt nur Valkey.
Commerce-Version
RemoteSynchronizedCache mit Valley
Empfohlene Konfiguration
2.4.8 und früher
(wenn Valkey unterstützt wird)
Unterstützt
VALKEY_BACKEND: '\Magento\Framework\Cache\Backend\RemoteSynchronizedCache'
2.4.9 und höher
Nicht unterstützt
VALKEY_BACKEND: 'symfony_l2'
IMPORTANT
Redis-Cache wird für Adobe Commerce 2.4.9 oder für Patch-Versionen nach 2.4.5-p16, 2.4.6-p14, 2.4.7-p9 und 2.4.8-p4 nicht unterstützt. Verwenden Sie Valley für die Cache-Konfiguration, bei der Redis nicht unterstützt wird. Siehe Systemanforderungen für unterstützte Cache-Services nach Version.
Valkey-Konfiguration

Verwenden Sie unter Commerce 2.4.8 und früheren Versionen, die Valkey unterstützen, diese Konfiguration:

code language-yaml 
stage:
  deploy:
    VALKEY_BACKEND: '\Magento\Framework\Cache\Backend\RemoteSynchronizedCache'

Verwenden Sie in Commerce 2.4.9 und höher die folgende Konfiguration mit der Symfony L2-Implementierung:

code language-yaml 
stage:
  deploy:
    VALKEY_BACKEND: 'symfony_l2'
Redis-Konfiguration

Verwenden Sie unter Version 2.4.8 und früheren Commerce-Versionen, die Redis unterstützen:

code language-yaml 
stage:
  deploy:
    REDIS_BACKEND: '\Magento\Framework\Cache\Backend\RemoteSynchronizedCache'

Weitere Informationen zur Umgebungskonfiguration finden Sie unter REDIS_BACKEND im Handbuch zu Commerce in Cloud-Infrastrukturen.

Migrieren nach Valkey mit Symfony L2-Cache

Wenn Sie ein vorhandenes Adobe Commerce on Cloud-Projekt von RemoteSynchronizedCache (Redis oder Valkey) nach symfony_l2 migrieren, lesen Sie Folgendes, bevor Sie .magento.env.yaml aktualisieren.

  • Die Bereitstellungsvariable muss geändert werden, um die symfony_l2 zu aktivieren. Wenn Sie VALKEY_BACKEND: symfony_l2 allein festlegen, wird die vollständige L2-Cache-Konfiguration automatisch erstellt. Sie müssen die backend_options Ihrer zuvor verwendeten RemoteSynchronizedCache-Konfiguration nicht manuell neu erstellen. Siehe Konfigurieren Symfony L2-Cache.

  • Entfernen Sie preload_keys aus Ihrer vorhandenen Konfiguration. Wenn Ihre RemoteSynchronizedCache-Konfiguration preload_keys unter CACHE_CONFIGURATION enthält, entfernen Sie sie im Rahmen der Migration. Siehe Vorabladen von Schlüsseln für Details.

  • Das veraltete Cache-Verhalten ändert sich automatisch. Unter symfony_l2 aktiviert ece-tools automatisch veralteten Cache für gängige Cache-Typen (z. B. layout, block_html, full_page und translate), ohne dass die erforderliche manuelle Frontend-Konfiguration erforderlich RemoteSynchronizedCache. Wenn Sie den veralteten Cache zuvor manuell konfiguriert haben und Ihr exaktes früheres Verhalten beibehalten möchten, lesen Sie Veralteten Cache aktivieren bevor Sie migrieren.

  • Komprimierung erfordert ein explizites Flag. Wenn Sie symfony_l2 Komprimierung über CACHE_CONFIGURATION anpassen, wird die Komprimierung durch Festlegen von compression_lib allein nicht aktiviert - compress_data muss ebenfalls festgelegt werden. Siehe Cache-Komprimierung.

  • Redis ist kein unterstütztes Remote-Backend für symfony_l2. Migrieren Sie im Rahmen dieser Änderung nach Valley. Siehe Einrichten des Valkey-Service.

  • Die Sitzungskonfiguration ist von dieser Migration nicht betroffen. SESSION_CONFIGURATION ist unabhängig vom Cache-Backend und muss beim Wechsel zu symfony_l2 nicht geändert werden. Siehe Trennen von Cache- und Sitzungsinstanzen.

IMPORTANT
Konfigurieren Sie symfony_l2 nicht manuell in app/etc/env.php. Konfigurieren Sie sie über .magento.env.yaml so, ece-tools die Einstellung während der Bereitstellung anwendet und beibehält. Siehe Konfigurieren Symfony L2-Cache.

Schlüssel vorausfüllen

Schlüssel zum Vorausfüllen können auf eine symfony_l2 angewendet werden, wenn Sie die richtige Platzierung verwenden (unter backend_options oder remote_backend_options). Es wird jedoch von Adobe nicht empfohlen, Preload-Schlüssel mit symfony_l2 zu verwenden. Die Implementierung der symfony_l2-Vorabladung ruft Schlüssel einzeln ab, sodass Roundtrips nicht so reduziert werden wie bei RemoteSynchronizedCache. Außerdem kann die Last auf Valkey erhöht werden, ohne dass ein Leistungsvorteil entsteht.

Mit der Vorabladefunktion können Sie eine Liste häufig verwendeter Schlüssel bereitstellen, die Adobe Commerce bei dem ersten Zugriff während einer Anfrage in einer einzigen Pipeline abruft. Adobe Commerce speichert die abgerufenen Werte dann für den Rest der Anfrage im PHP-Speicher, was die wiederholten Roundtrips zu Redis oder Valkey reduziert und die Bootstrap-Performance der Anfragen für diese Schlüssel verbessern kann.

Häufig verwendete Tasten können durch die Überwachung aktiver Befehle auf Redis oder Valley identifiziert werden:

Die Vorabladeschlüssel werden in der .magento.env.yaml-Konfigurationsdatei konfiguriert. Dieses Beispiel zeigt die Konfiguration für Adobe Commerce 2.4.8 und frühere Versionen, die RemoteSynchronizedCache unterstützen.

stage:
  deploy:
    REDIS_BACKEND: '\Magento\Framework\Cache\Backend\RemoteSynchronizedCache'
    CACHE_CONFIGURATION:
      _merge: true
      frontend:
        default:
          id_prefix: '061_' # Prefix for keys to be preloaded, it can be any random string
          backend_options:
            preload_keys: # List the keys to be preloaded
              - '061_EAV_ENTITY_TYPES:hash' # The key name must start with the id_prefix set above
              - '061_GLOBAL_PLUGIN_LIST:hash'
              - '061_DB_IS_UP_TO_DATE:hash'
              - '061_SYSTEM_DEFAULT:hash'

Um die Schlüssel aufzulisten, führen Sie den folgenden Befehl aus:

redis-cli -p 6370 -n 1 MONITOR > /tmp/list.keys

Drücken Sie nach 10 Sekunden Strg+C. Führen Sie dann den folgenden Befehl aus:

cat /tmp/list.keys | grep "HGET" | awk '{print $5}' | sort | uniq -c | sort -nr | head -n 50

In diesem Protokoll werden die Schlüssel aufgelistet, die Sie vorab laden können. Um den Inhalt eines Schlüssels anzuzeigen, führen Sie den folgenden Befehl aus:

redis-cli -p 6370 -n 1 hgetall "<key_name>"

Veralteten Cache aktivieren

Veralteter Cache ist eine L2-Cache-Funktion, mit der Adobe Commerce einen vorhandenen lokalen Cache-Wert aus /dev/shm bereitstellen kann, während derselbe Eintrag bereits durch eine andere Anfrage neu generiert wird. Dies verhindert, dass gleichzeitige Anfragen warten. Dadurch werden Cache-Stampedes und Sperrkonflikte bei der Neuerstellung teurer Cache-Einträge reduziert.

Legen Sie für Adobe Commerce 2.4.9 und höher VALKEY_BACKEND: symfony_l2 in der .magento.env.yaml fest:

stage:
  deploy:
    VALKEY_BACKEND: symfony_l2

ece-tools generiert automatisch sowohl ein default Frontend als auch ein stale_cache_enabled Frontend und ordnet dem veralteten Frontend die folgenden Cache-Typen zu: layout, block_html, reflection, config_integration, config_integration_api, full_page und translate. Für diese Typen ist keine manuelle use_stale_cache oder Frontend-Konfiguration erforderlich. Diese automatische Zuordnung ist selbst ein Beispiel für die Aktivierung des selektiven veralteten Caches. Nur bestimmte Cache-Typen verwenden das veraltete Frontend, nicht alle. Informationen zum Anpassen der stale_cache_enabled zugeordneten Typen oder zum Hinzufügen von Typen über die Standardwerte hinaus finden Sie unter Anpassen der L2 Symfony Cache-Konfiguration.

NOTE
Der full_page-Cache-Typ ist für Adobe Commerce in Cloud-Infrastrukturprojekten nicht relevant, da sie Fastly für die Zwischenspeicherung ganzer Seiten verwenden. In den manuellen Konfigurationsbeispielen in diesem Abschnitt werden full_page aus diesem Grund weggelassen, obwohl ece-tools sie in die standardmäßige symfony_l2-Zuordnung einbezieht.

Die folgende Konfiguration gilt für Adobe Commerce 2.4.8 und früher, die RemoteSynchronizedCache verwenden und manuellen veralteten Cache und Frontend-Konfiguration erfordern. Dieselbe selektive, globale Empfehlung gilt hier.

Funktionsweise des RemoteSynchronizedCache-Backends

Mit RemoteSynchronizedCache verwaltet Adobe Commerce zwei Kopien jedes Cache-Eintrags: eine lokale Kopie in /dev/shm und eine Remote-Kopie in Redis oder Valkey. Wenn die Remote Copy nicht verfügbar ist und bereits eine Regenerierungssperre für diesen Schlüssel vorhanden ist, können gleichzeitige -Anfragen den vorherigen lokalen Wert empfangen, anstatt zu warten, bis der neue Wert geschrieben wird.

Um den veralteten Cache für 2.4.8 und frühere Versionen zu aktivieren, konfigurieren Sie ihn in der .magento.env.yaml.

stage:
  deploy:
    REDIS_BACKEND: '\Magento\Framework\Cache\Backend\RemoteSynchronizedCache'
    CACHE_CONFIGURATION:
      _merge: true
      frontend:
        default:
          backend_options:
            use_stale_cache: true
WARNING
Die obige Konfiguration ermöglicht veralteten Cache im Frontend für den default-Cache, das veraltetes Cache-Verhalten auf alle Cache-Einträge anwendet, die dieses Frontend verwenden. Adobe Commerce Core-Cache-Typen funktionieren mit dieser Einstellung erwartungsgemäß. Wenn Ihr Projekt jedoch benutzerdefinierten Code oder Erweiterungen enthält, die über die generische \Magento\Framework\App\Cache-API (z. B. $this->cache->save()) ohne dediziertes Cache-Frontend in den Cache schreiben, können diese Einträge während der Regenerierung auch veraltete Werte liefern.
Wenn dies zu unerwartetem Verhalten in Ihren Anpassungen führt, lassen Sie den veralteten Cache im default-Frontend deaktiviert und aktivieren Sie ihn nur für ausgewählte Cache-Typen, wie unten dargestellt.

Veralteten Cache pro Cache-Typ einzeln aktivieren (RemoteSynchronizedCache)

Sie können veralteten Cache nur für ausgewählte Cache-Typen aktivieren, indem Sie ein dediziertes Cache-Frontend in .magento.env.yaml definieren und die ausgewählten Cache-Typen ihm zuordnen. Dieser manuelle Ansatz gilt für das RemoteSynchronizedCache-Backend. symfony_l2 führt diese Zuordnung wie oben beschrieben automatisch durch.

Um ordnungsgemäß zu funktionieren, muss das benutzerdefinierte Frontend als vollständiges Frontend unter CACHE_CONFIGURATION.frontend definiert werden. Es reicht nicht aus, nur use_stale_cache: true für einen neuen Frontend-Namen zu definieren.

Beispielkonfigurationen

Für Redis ab Version 2.4.8 aktiviert die folgende Konfiguration veralteten Cache für die Cache-Typen layout, reflection, config_integration, config_integration_api und translate, während andere mit dem standardmäßigen Frontend mit deaktiviertem veralteten Cache verbleiben:

stage:
  deploy:
    REDIS_BACKEND: '\Magento\Framework\Cache\Backend\RemoteSynchronizedCache'
    CACHE_CONFIGURATION:
      _merge: true
      frontend:
        default: # In this frontend, we keep stale cache set to false.
          id_prefix: '001_'
          backend_options:
            use_stale_cache: false

        # Now, create a new frontend called 'stale_cache_enabled'.
        # It must contain the same backend connection settings as the frontend 'default':

        stale_cache_enabled:
          id_prefix: '001_'
          backend: '\Magento\Framework\Cache\Backend\RemoteSynchronizedCache'
          backend_options:
            remote_backend: '\Magento\Framework\Cache\Backend\Redis'
            remote_backend_options:
              server: localhost
              port: 6370 # Use the same port used by the frontend 'default' in env.php
              database: 1
              load_from_slave:
                server: localhost
                port: 26370 # Use the same port used by the frontend 'default' in env.php
              retry_reads_on_master: 1
              read_timeout: 10
            local_backend: 'Cm_Cache_Backend_File'
            local_backend_options:
              cache_dir: /dev/shm/
            use_stale_cache: true # stale cache here is enabled

      # Now select which cache types you want to enable (stale_cache_enabled), or disable (default)

      type:
        default:
          frontend: default
        layout:
          frontend: stale_cache_enabled
        reflection:
          frontend: stale_cache_enabled
        config_integration:
          frontend: stale_cache_enabled
        config_integration_api:
          frontend: stale_cache_enabled
        translate:
          frontend: stale_cache_enabled
        # add other cache types as needed...
NOTE
Wenn das Quell-Frontend mit zusätzlichen Backend-Optionen konfiguriert ist, kopieren Sie diese Optionen in stale_cache_enabled, damit das neue Frontend dasselbe Verhalten beibehält.

Konfigurieren Symfony L2-Cache

Adobe Commerce 2.4.9 und höher unterstützt das symfony_l2-Cache-Backend. Das symfony_l2-Backend ist die Cache-Implementierung, die Adobe Commerce verwendet, um das L1- und L2-Cache-Verhalten zu verwalten. Redis oder Valkey als Remote-Cache-Service werden nicht ersetzt.

IMPORTANT
Konfigurieren Sie symfony_l2 über die .magento.env.yaml Bereitstellungsvariable so, ece-tools die Einstellung während der Bereitstellung angewendet und beibehalten wird. Konfigurieren Sie symfony_l2 nicht manuell in app/etc/env.php, da die Bereitstellung manuelle env.php überschreiben kann. Wenn ece-tools keine symfony_l2 anwendet, kann Commerce auf dateibasierten Cache zurückgreifen, was den Festplatten-E/A erhöhen, den Dateisystem-Replikationsaufwand in Umgebungen mit mehreren Knoten erhöhen und die Leistung beeinträchtigen kann.

Um symfony_l2 Cache für Adobe Commerce 2.4.9 zu verwenden, führen Sie die folgenden Schritte aus:

  • Aktualisieren Sie auf die neueste Version des ece-tools. Sie müssen das ECE-Tools-Paket v2002.2.13 oder höher verwenden.

  • Legen Sie die Bereitstellungsvariable in der .magento.env.yaml fest: VALKEY_BACKEND=symfony_l2.

    code language-yaml 
    stage:
  deploy:
    VALKEY_BACKEND: symfony_l2

Wenn Sie die VALKEY_BACKEND Bereitstellungsvariable auf symfony_l2 setzen, wird automatisch die vollständige L2-Cache-Konfiguration aus Ihren Valkey-Service-Verbindungsdetails erstellt, einschließlich default und stale_cache_enabled-Frontends, wobei die gängigen Cache-Typen bereits zugeordnet sind. Die Definition von CACHE_CONFIGURATION ist optional und nur erforderlich, wenn Sie bestimmte Backend-Optionen anpassen möchten.

NOTE
Patch von ACP2E-5132 für Adobe Commerce 2.4.9 verbessert die Leistung und Zuverlässigkeit Symfony L2-Cache. Er optimiert die Tag-Speicherung, fügt eine veraltete Cache-Regenerationssperre hinzu und behebt Probleme mit veralteten Tag-Mitgliedschaften, redundanten Remote-Schreibvorgängen und einer L1-Größenbasierten Entfernung (cleanup_percentage). Dadurch werden Datenträger-E/A und Backend-Last reduziert und gleichzeitig die Cache-Konsistenz verbessert. Siehe Verbesserte Leistung und Zuverlässigkeit des Symfony L2Cache im Adobe Commerce-Konfigurationshandbuch.
Der Patch ist im Paket Cloud-Patches für Commerce enthalten (eine Abhängigkeit von ece-tools) und wird automatisch während der Bereitstellung angewendet, wenn Sie auf die neueste ece-tools aktualisieren. Aktualisieren Sie auf die neueste Version von ece-tools, um den Patch zu erhalten.

Anpassen der Symfony L2-Cache-Konfiguration

ece-tools leitet automatisch die Valkey-Verbindungsdetails (server, port, database, serializer, compression_lib, persistent_id) für die default und stale_cache_enabled Frontends ab. Um andere Backend-Optionen anzupassen, z. B. das lokale Cache-Verzeichnis, definieren Sie CACHE_CONFIGURATION mit _merge: true neben VALKEY_BACKEND: symfony_l2. Die hier definierten Werte überschreiben die entsprechenden automatisch generierten Standardwerte. Alle Optionen, die Sie weglassen, verwenden weiterhin die automatisch von ece-tools abgeleiteten Werte.

stage:
  deploy:
    VALKEY_BACKEND: symfony_l2
    CACHE_CONFIGURATION:
      _merge: true
      frontend:
        default:
          backend_options:
            remote_backend: valkey
            local_backend: file
            local_backend_options:
              cache_dir: /dev/shm/magento_l1
        stale_cache_enabled:
          backend: symfony_l2
          backend_options:
            remote_backend: valkey
            local_backend: file
            local_backend_options:
              cache_dir: /dev/shm/magento_l1_stale
            use_stale_cache: true
CAUTION
Überschreiben Sie beim Definieren von CACHE_CONFIGURATION für symfony_l2 nur server oder port, wenn Sie absichtlich auf einen anderen Cache-Endpunkt als den Valkey-Service Ihres Projekts verweisen. Das ece-tools leitet diese Werte automatisch von Ihrer Valkey-Service-Beziehung ab.
Wenn Sie server überschreiben, muss sein Wert beim Herstellen einer Verbindung mit dem Valkey-Service des Projekts localhost werden. Wenn Sie einen falschen server- oder port angeben, schlägt die Bereitstellung mit einem Cache-Verbindungsfehler fehl.

L2-Cache-Speicherdimensionierung für Adobe Commerce Cloud

Der L2-Cache nutzt ein temporäres Dateisystem (/dev/shm) als Speichermechanismus. Im Gegensatz zu spezialisierten Schlüssel-Wert-Speichern gibt es bei tmpfs keine Richtlinie zum Entfernen von Schlüsseln, sodass die Speichernutzung unbegrenzt ansteigen kann. Um eine Überlastung zu vermeiden, löscht Adobe Commerce automatisch den L2-Speicher, wenn die Nutzung einen konfigurierbaren Schwellenwert erreicht (standardmäßig 95 %). Sie können den Speicherverbrauch kontrollieren, indem Sie eine größere /dev/shm anfordern oder den Bereinigungsschwellenwert senken.

Passen Sie die maximale L2-Cache-Speichernutzung an Ihre Projektanforderungen an. Verwenden Sie eine der folgenden Methoden:

  • Erstellen Sie ein Support-Ticket, um die Größe der /dev/shm-Halterung anzupassen. Für dieses Szenario empfiehlt Adobe, die /dev/shm-Bereitstellungsgröße auf 15 GB festzulegen.
  • Passen Sie die cleanup_percentage Eigenschaft auf Anwendungsebene an, um die Speicherauslastung zu begrenzen und den für andere Services verfügbaren freien Speicher zu nutzen.
    Sie können die Konfiguration in der Bereitstellungskonfiguration unter der Cache-Konfigurationsgruppe cache/frontend/default/backend_options/cleanup_percentage anpassen.
NOTE
Die cleanup_percentage konfigurierbare Option wurde in Adobe Commerce 2.4.4 eingeführt.

Die folgenden Beispiele zeigen den Konfigurations-Code in der .magento.env.yaml:

Valkey-Konfiguration

Verwenden Sie für Commerce 2.4.9 und höher die folgende Konfiguration, um den Bereinigungsschwellenwert auf 90 % festzulegen:

code language-yaml 
stage:
  deploy:
    VALKEY_BACKEND: symfony_l2
    CACHE_CONFIGURATION:
      _merge: true
      frontend:
        default:
          backend_options:
            cleanup_percentage: 90
Redis-Konfiguration

Verwenden Sie für Commerce 2.4.8 und früher die folgende Konfiguration, um den Bereinigungsschwellenwert auf 90 % festzulegen:

code language-yaml 
stage:
  deploy:
    REDIS_BACKEND: '\Magento\Framework\Cache\Backend\RemoteSynchronizedCache'
    CACHE_CONFIGURATION:
      _merge: true
      frontend:
        default:
          backend_options:
            cleanup_percentage: 90

Die Cache-Anforderungen variieren je nach Projektkonfiguration und benutzerdefiniertem Code von Drittanbietern. Größe des L2-Cache-Speichers, damit der Cache ohne häufige Schwellenwerttreffer arbeiten kann.

Idealerweise bleibt die Speicherauslastung des L2-Cache unter dem Schwellenwert, um eine häufige Speicherbereinigung zu vermeiden.

Sie können die Speicherauslastung des L2-Cache auf jedem Knoten des Clusters überprüfen, indem Sie den folgenden CLI-Befehl ausführen und die /dev/shm Zeile überprüfen.

df -h /dev/shm

Die Nutzung variiert je nach Knoten, konvergiert jedoch zu einem ähnlichen Wert.

Konfigurationsbeispiele

Verwenden Sie die folgenden Beispiele als Ausgangspunkt für Ihre Redis- oder Valley-Service-Konfigurationen.

Anwendung aller Best Practice-Empfehlungen

Beispiel mit VALKEY_BACKEND

Generieren ece-tools VALKEY_BACKEND: symfony_l2 die default- und stale_cache_enabled-Frontends und deren Cache-Typ-Zuordnungen. Legen Sie keine use_stale_cache auf der Frontend-default fest. Der nachstehende CACHE_CONFIGURATION-Block enthält nur explizite Überschreibungen der Backend-Optionen.

code language-yaml 
stage:
  deploy:
    MYSQL_USE_SLAVE_CONNECTION: true
    VALKEY_USE_SLAVE_CONNECTION: true # Enables read-only replica connection logic in Magento. It also works in a split architecture.
    VALKEY_BACKEND: symfony_l2 # Use symfony_l2 for Adobe Commerce 2.4.9 and later
    CACHE_CONFIGURATION:
      _merge: true
      frontend:
        default:
          id_prefix: '001_' # any prefix is fine, but keep it consistent.
          backend_options:
            connect_retries: 3                # Number of connection retries
            remote_backend_options:
              read_timeout: 10
              retry_reads_on_master: 1        # Required for split architecture
            # Keep compression disabled for maximum performance. Only enable it if the cache usage is approaching the limit defined in maxmemory:
            # compress_data: 4              # 0-9
            # compress_tags: 4              # 0-9
            # compress_threshold: 20480     # don't compress files smaller than this value
            # compression_lib: 'gzip'       # snappy and lzf for performance, gzip for high compression (~69%)

    SESSION_CONFIGURATION:
      _merge: true
      redis:
        # port: 6372 # ece-tools should detect the port automatically, but if not, set here.
        timeout: 5
        disable_locking: 1 # true for max performance. If racing conditions happen when the server has an excessively high number of simultaneous session activities, set it to false.
        bot_first_lifetime: 60
        bot_lifetime: 7200
        max_lifetime: 2592000
        min_lifetime: 60
Beispiel mit REDIS_BACKEND
code language-yaml 
stage:
  deploy:
    MYSQL_USE_SLAVE_CONNECTION: true
    REDIS_USE_SLAVE_CONNECTION: true # Enables read-only replica connection logic in Magento. It also works in a split architecture
    REDIS_BACKEND: \Magento\Framework\Cache\Backend\RemoteSynchronizedCache
    CACHE_CONFIGURATION:
      _merge: true
      frontend:
        default:
          id_prefix: '001_' # Any prefix is fine, but keep it consistent.
          backend_options:
            use_stale_cache: true             # Enables stale cache feature for all cache types
            connect_retries: 3                # Number of connection retries
            preload_keys:                     # Preload keys at backend_options level (official Adobe placement)
              - '001_EAV_ENTITY_TYPES:hash'   # Bootstrap: entity types
              - '001_GLOBAL_PLUGIN_LIST:hash' # Bootstrap: DI plugin list
              - '001_DB_IS_UP_TO_DATE:hash'   # Bootstrap: schema version
              - '001_SYSTEM_DEFAULT:hash'     # Config: system defaults
              - '001_EXTENSION_ATTRIBUTES_CONFIG:hash'
            remote_backend_options:
              read_timeout: 10
              retry_reads_on_master: 1        # Required for split architecture
            # Keep compression disabled for maximum performance. Only enable it if the cache usage is approaching the limit defined in maxmemory:
            # compress_data: 4              # 0-9
            # compress_tags: 4              # 0-9
            # compress_threshold: 20480     # don't compress files smaller than this value
            # compression_lib: 'gzip'       # snappy and lzf for performance, gzip for high compression (~69%)

    SESSION_CONFIGURATION:
      _merge: true
      redis:

        # port: 6372 # ece-tools should detect the port automatically, but if not, set here.

        timeout: 5
        disable_locking: 1 # true for max performance. If racing conditions happen when the server has an excessively high number of simultaneous session activities, set it to false.
        bot_first_lifetime: 60
        bot_lifetime: 7200
        max_lifetime: 2592000
        min_lifetime: 60

Veralteten Cache nach Cache-Typ trennen

Beispiel mit VALKEY_BACKEND
code language-yaml 
stage:
  deploy:
    MYSQL_USE_SLAVE_CONNECTION: true
    VALKEY_USE_SLAVE_CONNECTION: true # Enables read-only replica connection logic in Magento. It also works in a split architecture
    VALKEY_BACKEND: symfony_l2 # Use symfony_l2 for Adobe Commerce 2.4.9 and later
    CACHE_CONFIGURATION:
      _merge: true
      frontend:
        default: # Keep stale cache disabled on the broad default frontend.
          id_prefix: '001_' # Keep this prefix consistent with the frontend configuration generated in env.php
          backend_options:
            connect_retries: 3
            remote_backend_options:
              read_timeout: 10
              retry_reads_on_master: 1
            # Keep compression disabled for maximum performance. Only enable it if the cache usage is approaching the limit defined in maxmemory:
            # compress_data: 4
            # compress_tags: 4
            # compress_threshold: 20480
            # compression_lib: 'gzip'

        stale_cache_enabled: # New frontend with stale cache enabled only for selected cache types.
          id_prefix: '001_' # Use the same id_prefix used by the source frontend in env.php
          backend: symfony_l2
          backend_options:
            remote_backend: valkey
            remote_backend_options:
              server: localhost
              port: 6370   # Use the same port used by the source frontend in env.php
              database: 1
              load_from_slave:
                server: localhost
                port: 26370 # Use the same read-only replica connection/read port used by the source frontend in env.php
              retry_reads_on_master: 1
              read_timeout: 10
            local_backend: file
            local_backend_options:
              cache_dir: /dev/shm/
            use_stale_cache: true
            connect_retries: 3
            # Keep compression disabled for maximum performance. Only enable it if the cache usage is approaching the limit defined in maxmemory:
            # compress_data: 4
            # compress_tags: 4
            # compress_threshold: 20480
            # compression_lib: 'gzip'

      type:
        default:
          frontend: default # Keeps stale cache disabled on the broad default frontend, including generic cache writes that use \Magento\Framework\App\Cache, such as $this->cache->save().
        block_html:
          frontend: stale_cache_enabled # This is often one of the cache types that benefits the most from stale cache, because it is heavily used and can contribute significantly to lock contention during regeneration. In most cases, it can remain enabled. Exclude it only if the project has customization-specific issues caused by stale block output.
        layout:
          frontend: stale_cache_enabled
        reflection:
          frontend: stale_cache_enabled
        config_integration:
          frontend: stale_cache_enabled
        config_integration_api:
          frontend: stale_cache_enabled
        translate:
          frontend: stale_cache_enabled
        # add other cache types as needed...

    SESSION_CONFIGURATION:
      _merge: true
      redis: # keep 'redis' even if you are using Valkey.
        # port: 6372 # ece-tools should detect the port automatically, but if not, set here.
        timeout: 5
        disable_locking: 1 # true for max performance. If racing conditions happen when the server has an excessively high number of simultaneous session activities, set it to false.
        bot_first_lifetime: 60
        bot_lifetime: 7200
        max_lifetime: 2592000
        min_lifetime: 60
Beispiel mit REDIS_BACKEND
code language-yaml 
stage:
  deploy:
    MYSQL_USE_SLAVE_CONNECTION: true
    REDIS_USE_SLAVE_CONNECTION: true # Enables read-only replica connection logic in Magento. It also works in a split architecture
    REDIS_BACKEND: \Magento\Framework\Cache\Backend\RemoteSynchronizedCache
    CACHE_CONFIGURATION:
      _merge: true
      frontend:
        default: # Keep stale cache disabled on the broad default frontend.
          id_prefix: '001_' # Keep this prefix consistent with the frontend configuration generated in env.php
          backend_options:
            use_stale_cache: false # stale cache false here
            connect_retries: 3
            preload_keys:
              - '001_EAV_ENTITY_TYPES:hash'
              - '001_GLOBAL_PLUGIN_LIST:hash'
              - '001_DB_IS_UP_TO_DATE:hash'
              - '001_SYSTEM_DEFAULT:hash'
              - '001_EXTENSION_ATTRIBUTES_CONFIG:hash'
            remote_backend_options:
              read_timeout: 10
              retry_reads_on_master: 1
            # Keep compression disabled for maximum performance. Only enable it if the cache usage is approaching the limit defined in maxmemory:
            # compress_data: 4
            # compress_tags: 4
            # compress_threshold: 20480
            # compression_lib: 'gzip'

        stale_cache_enabled: # New frontend with stale cache enabled only for selected cache types.
          id_prefix: '001_' # Use the same id_prefix used by the source frontend in env.php
          backend: \Magento\Framework\Cache\Backend\RemoteSynchronizedCache
          backend_options:
            remote_backend: \Magento\Framework\Cache\Backend\Redis
            remote_backend_options:
              server: localhost
              port: 6370   # Use the same port used by the source frontend in env.php
              database: 1
              load_from_slave:
                server: localhost
                port: 26370 # Use the same read-only replica connection/read port used by the source frontend in env.php
              retry_reads_on_master: 1
              read_timeout: 10
            local_backend: Cm_Cache_Backend_File
            local_backend_options:
              cache_dir: /dev/shm/
            use_stale_cache: true
            connect_retries: 3
            preload_keys:
              - '001_EAV_ENTITY_TYPES:hash'
              - '001_GLOBAL_PLUGIN_LIST:hash'
              - '001_DB_IS_UP_TO_DATE:hash'
              - '001_SYSTEM_DEFAULT:hash'
              - '001_EXTENSION_ATTRIBUTES_CONFIG:hash'
            # Keep compression disabled for maximum performance. Only enable it if the cache usage is approaching the limit defined in maxmemory:
            # compress_data: 4
            # compress_tags: 4
            # compress_threshold: 20480
            # compression_lib: 'gzip'

      type:
        default:
          frontend: default # Keeps stale cache disabled on the broad default frontend, including generic cache writes that use \Magento\Framework\App\Cache, such as $this->cache->save().
        block_html:
          frontend: stale_cache_enabled # This is often one of the cache types that benefits the most from stale cache, because it is heavily used and can contribute significantly to lock contention during regeneration. In most cases, it can remain enabled. Exclude it only if the project has customization-specific issues caused by stale block output.
        layout:
          frontend: stale_cache_enabled
        reflection:
          frontend: stale_cache_enabled
        config_integration:
          frontend: stale_cache_enabled
        config_integration_api:
          frontend: stale_cache_enabled
        translate:
          frontend: stale_cache_enabled
        # add other cache types as needed...

    SESSION_CONFIGURATION:
      _merge: true
      redis:
        # port: 6372 # ece-tools should detect the port automatically, but if not, set here.
        timeout: 5
        disable_locking: 1 # true for max performance. If racing conditions happen when the server has an excessively high number of simultaneous session activities, set it to false.
        bot_first_lifetime: 60
        bot_lifetime: 7200
        max_lifetime: 2592000
        min_lifetime: 60

Weitere Informationen

Siehe die folgenden verwandten Themen:

recommendation-more-help
commerce-operations-help-implementation-playbook