DocumentazioneCommercePlaybook di implementazione

[Solo PaaS]{class="badge informative" title="Applicabile solo ai progetti Adobe Commerce on Cloud (infrastruttura PaaS gestita da Adobe) e ai progetti on-premise."}

Best practice per la configurazione del servizio Redis e Valkey

Last update: Mon Apr 06 2026 00:00:00 GMT+0000 (Coordinated Universal Time)

Creato per:

  • Intermedio
  • Sviluppatore
  • Amministratore

Utilizza questi consigli per configurare Redis o Valkey per il caching e le sessioni di Adobe Commerce.

  • Configurare la cache L2
  • Abilita connessione slave
  • Precarica chiavi
  • Abilita cache non aggiornata
  • Cache e sessione separate
  • Comprimi la cache
  • Esempi di configurazione
NOTE
Per gli ambienti dell'infrastruttura Commerce on Cloud, verificare di utilizzare la versione più recente del pacchetto ece-tools. In caso contrario, aggiorna alla versione più recente. È possibile controllare la versione installata nell'ambiente locale utilizzando il comando CLI composer show magento/ece-tools.

Configurare la cache L2

Configurare la cache L2 impostando la variabile di distribuzione REDIS_BACKEND o VALKEY_BACKEND nel file di configurazione .magento.env.yaml.

Configurazione Redis

Per Redis, utilizzare:

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

Per la configurazione dell'ambiente nell'infrastruttura cloud, vedere il riferimento alla configurazione REDIS_BACKEND nella Guida all'infrastruttura cloud di Commerce.

Per le installazioni locali, vedere Configure Redis page caching nella Guida alla configurazione.

Configurazione Valkey

Per Valkey, utilizzare:

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

Per la configurazione dell'ambiente nell'infrastruttura cloud, vedere il riferimento alla configurazione VALKEY_BACKEND nella Guida all'infrastruttura cloud di Commerce.

Per le installazioni locali, vedere Configure Valkey in Configuration Guide.

Dimensioni della memoria cache L2 per Adobe Commerce Cloud

La cache L2 utilizza un file system temporaneo (/dev/shm) come meccanismo di archiviazione. A differenza degli archivi specializzati di valori chiave, i tmpfs non dispongono di criteri di rimozione delle chiavi, pertanto l'utilizzo della memoria può crescere senza limiti. Per evitare l’esaurimento, Adobe Commerce cancella automaticamente lo storage L2 quando l’utilizzo raggiunge una soglia configurabile (95% per impostazione predefinita). È possibile controllare il consumo di memoria richiedendo un montaggio /dev/shm più grande o abbassando la soglia di pulizia.

Regola l’utilizzo massimo della memoria cache L2 in base ai requisiti del progetto. Utilizza uno dei seguenti metodi:

  • Creare un ticket di supporto per regolare la dimensione di montaggio /dev/shm. Per questo scenario, Adobe consiglia di impostare la dimensione di montaggio /dev/shm su 15 GB.
  • Regolare la proprietà cleanup_percentage a livello di applicazione per limitare l'utilizzo dello spazio di archiviazione e della memoria disponibile per altri servizi.
    È possibile modificare la configurazione nella configurazione di distribuzione nel gruppo di configurazione della cache cache/frontend/default/backend_options/cleanup_percentage.
NOTE
L'opzione configurabile cleanup_percentage è stata introdotta in Adobe Commerce 2.4.4.

Gli esempi seguenti mostrano il codice di configurazione nel file .magento.env.yaml:

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

I requisiti della cache dipendono dalla configurazione del progetto e dal codice personalizzato di terze parti. Dimensione della memoria cache L2 in modo che la cache possa funzionare senza frequenti hit di soglia.

Idealmente, l'utilizzo della memoria cache L2 si stabilizza al di sotto della soglia per evitare frequenti cancellazioni dello storage.

È possibile verificare l'utilizzo della memoria di archiviazione nella cache L2 in ogni nodo del cluster eseguendo il seguente comando CLI e rivedendo la riga /dev/shm.

df -h /dev/shm

L’utilizzo può variare tra i nodi, ma deve convergere in un valore simile.

Configurare directory personalizzate per la cache L2

Quando si ottimizzano le prestazioni della cache L2, è possibile scegliere di memorizzare i file della cache locale in una directory personalizzata ad alte prestazioni, ad esempio un disco RAM (/dev/shm/).

Per garantire la coerenza a livello di applicazione ed evitare la frammentazione dell'archiviazione della cache, configurare sia le opzioni specifiche del back-end L2 che il Registro di sistema della directory globale nel file app/etc/env.php.

Best practice: Definisci sia local_backend_options['cache_dir'] che il directories['cache']['path'] globale.

  • local_backend_options['cache_dir']: indirizza l'adattatore cache back-end (ad esempio, Cm_Cache_Backend_File) a memorizzare i file della cache L2 sincronizzati nel percorso specificato.
  • directories['cache']['path']: aggiorna il Registro di sistema di Adobe Commerce DirectoryList, stabilendo il percorso personalizzato come directory definitiva della cache di sistema per l'intera applicazione.

Impedisci la suddivisione delle directory della cache e errori di segmentazione GlusterFS

Se si definisce il percorso personalizzato esclusivamente in local_backend_options, il motore di cache L2 funziona correttamente, ma il Registro di sistema globale dell'applicazione continua a riconoscere var/cache come percorso di cache predefinito.

Questa mancata corrispondenza di configurazione determina uno scenario "split-brain" in cui estensioni di terze parti o processi di fallback di base scrivono file temporanei nella directory predefinita var/cache.

Impatto critico su Adobe Commerce Cloud: Nelle architetture Pro, la directory var/ è montata su un file system distribuito condiviso. L'imposizione dell'I/O della cache ad alta velocità su questo montaggio di rete sovraccarica il client ed è un trigger primario per errori di segmentazione GlusterFS e interruzioni a livello di cluster. La configurazione di entrambe le impostazioni garantisce che tutti gli I/O della cache rimangano rigorosamente sul disco locale ad alte prestazioni.

Esempio di configurazione

Per applicare un'unica directory cache unificata, aggiornare il file env.php in modo da includere entrambe le configurazioni:

return [
    // 1. Override the global directory registry
    'directories' => [
        'cache' => [
            'path' => '/dev/shm/magento_cache'
        ]
    ],
    // 2. Configure the L2 cache engine
    'cache' => [
        'frontend' => [
            'default' => [
                'backend' => '\\Magento\\Framework\\Cache\\Backend\\RemoteSynchronizedCache',
                'backend_options' => [
                    'remote_backend' => '\\Magento\\Framework\\Cache\\Backend\\Redis',
                    'server' => '127.0.0.1',
                    'port' => '6379',
                    'database' => '1',
                    // ... other redis configurations ...
                    'local_backend' => 'Cm_Cache_Backend_File',
                    'local_backend_options' => [
                        'cache_dir' => '/dev/shm/magento_cache'
                    ]
                ]
            ]
        ]
    ],
    // ...
];

Abilita connessione slave

Abilitare la connessione slave nel file .magento.env.yaml per consentire ad Adobe Commerce di utilizzare una connessione cache di sola lettura aggiuntiva per le operazioni di lettura mentre si continua a utilizzare l'endpoint primario per le operazioni di scrittura. Questa configurazione può ridurre il carico di lettura sul servizio di cache principale e distribuire il traffico di lettura in modo più efficace.

Configurazione Redis

Per Redis, utilizzare:

code language-yaml 
stage:
  deploy:
    REDIS_USE_SLAVE_CONNECTION: true

Per la configurazione dell'ambiente nell'infrastruttura Commerce Cloud, vedere REDIS_USE_SLAVE_CONNECTION nella Guida di Commerce sull'infrastruttura cloud.

Per le installazioni Adobe Commerce locali, configurare la nuova implementazione della cache Redis utilizzando i comandi bin/magento setup. Vedere Utilizzare Redis per la cache predefinita nella Guida alla configurazione.

Configurazione Valkey

Per Valkey, utilizzare:

code language-yaml 
stage:
  deploy:
    VALKEY_USE_SLAVE_CONNECTION: true

Per la configurazione dell'ambiente nell'infrastruttura Commerce Cloud, vedere VALKEY_USE_SLAVE_CONNECTION nella Guida di Commerce sull'infrastruttura cloud.

Per le installazioni locali di Adobe Commerce, configura la nuova implementazione della cache di Valkey utilizzando i comandi bin/magento setup. Vedi Configurazione di Valkey nella Guida alla configurazione.

Precarica chiavi

Magento in genere carica le voci della cache da Redis o Valkey una chiave alla volta. La funzione di precaricamento ti consente di fornire un elenco di chiavi utilizzate di frequente che Magento recupera in una singola pipeline al primo accesso durante una richiesta. Magento mantiene quindi i valori recuperati nella memoria PHP per il resto di tale richiesta, riducendo i round trip ripetuti a Redis o Valkey e migliorando le prestazioni di bootstrap delle richieste per tali chiavi.

Puoi identificare le chiavi utilizzate di frequente monitorando i comandi attivi su Redis o Valkey:

Redis configurazione chiave di precaricamento

Le chiavi di precaricamento sono configurate nel file di configurazione .magento.env.yaml.

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'

Per elencare le chiavi, eseguire il comando seguente:

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

Dopo 10 secondi, premere Ctrl+C. Quindi esegui il seguente comando:

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

In questo registro sono elencate le chiavi che è possibile precaricare. Per visualizzare il contenuto di una chiave, eseguire il comando seguente:

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

Per le installazioni locali, vedere Funzionalità di precaricamento Redis nella Guida alla configurazione.

Configurazione chiave di precaricamento Valkey

Le chiavi di precaricamento sono configurate nel file di configurazione .magento.env.yaml.

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'

Per elencare le chiavi, eseguire il comando seguente:

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

Dopo 10 secondi, premere Ctrl+C. Quindi esegui il seguente comando:

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

In questo registro sono elencate le chiavi che è possibile precaricare. Per visualizzare il contenuto di una chiave, eseguire il comando seguente:

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

Per le installazioni locali, vedere Funzionalità di precaricamento Valkey nella Guida alla configurazione.

Abilita cache non aggiornata

La cache non aggiornata è una funzionalità della cache L2 di RemoteSynchronizedCache. Se abilitata, Adobe Commerce può distribuire un valore della cache locale esistente da /dev/shm mentre un'altra richiesta sta già rigenerando la stessa voce, invece di fare attendere ogni richiesta concorrente. Questo riduce gli stamp della cache e i conflitti di blocco durante la rigenerazione di voci costose della cache.

Come funziona

Con RemoteSynchronizedCache, Magento mantiene due copie di ogni voce della cache: una copia locale in /dev/shm e una copia remota in Redis o Valkey. Quando la copia remota non è disponibile ed esiste già un blocco di rigenerazione per tale chiave, le richieste simultanee possono ricevere il valore locale precedente invece di attendere che venga scritto il nuovo valore.

Per abilitare la cache non aggiornata, configurarla nel file .magento.env.yaml.

Configura cache non aggiornata per Redis

Per 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
Configura cache non aggiornata per Valkey

Per Valkey:

code language-yaml 
stage:
  deploy:
    VALKEY_BACKEND: '\Magento\Framework\Cache\Backend\RemoteSynchronizedCache'
    CACHE_CONFIGURATION:
      _merge: true
      frontend:
        default:
          backend_options:
            use_stale_cache: true
NOTE
Il tipo di cache full_page non è rilevante per i progetti di infrastruttura Adobe Commerce on Cloud perché utilizza Fastly.

Per le installazioni locali, vedere Opzioni cache non aggiornate nella Guida alla configurazione.

WARNING
La configurazione precedente abilita la cache non aggiornata nel front-end della cache default, che applica il comportamento di cache non aggiornata a tutte le voci della cache che utilizzano tale front-end. I tipi di cache di base di Magento generalmente funzionano come previsto con questa impostazione. Tuttavia, se il progetto include codice personalizzato o estensioni che scrivono nella cache tramite l'API generica \Magento\Framework\App\Cache (ad esempio $this->cache->save()) senza una cache front-end dedicata, tali voci possono anche fornire valori non aggiornati durante la rigenerazione.
Se si verifica un comportamento imprevisto nelle personalizzazioni, lasciare disabilitata la cache non aggiornata nel front-end default e abilitarla solo per i tipi di cache selezionati, come avviene di solito in locale.

Abilitazione di una cache non aggiornata singolarmente per tipo di cache

È possibile abilitare una cache non aggiornata solo per i tipi di cache selezionati definendo una cache front-end dedicata in .magento.env.yaml e mappando i tipi di cache selezionati.

Per funzionare correttamente, il front-end personalizzato deve essere definito come front-end completo in CACHE_CONFIGURATION.frontend. Non è sufficiente definire solo use_stale_cache: true per un nuovo nome front-end.

Configurazioni di esempio

Configura cache non aggiornata per Redis

Per 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...
Configura cache non aggiornata per Valkey

Per Valkey:

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\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
Se il front-end di origine è configurato con opzioni di back-end aggiuntive, ad esempio compressione, nuovi tentativi, chiavi di precaricamento o altri valori di tuning, copiare tali opzioni in stale_cache_enabled in modo che il nuovo front-end mantenga lo stesso comportamento.

Istanze di sessione e cache separate

La separazione della cache dalle sessioni consente di gestirle in modo indipendente. Riduce il conflitto tra la cache e il traffico di sessione, evita che la pressione relativa alla cache influisca sulle sessioni e consente di ridimensionare e regolare ogni istanza Redis o Valkey per il proprio carico di lavoro.

Segui i passaggi seguenti per effettuare il provisioning di un’istanza dedicata per le sessioni:

Redis

  1. Aggiornare il file di configurazione .magento/services.yaml.

    code language-yaml 
    mysql:
  type: mysql:10.4
  disk: 35000

redis:
  type: redis:6.0

redis-session: # This is for the new Redis instance
  type: redis:6.0

search:
  type: elasticsearch:7.9
  disk: 5000

rabbitmq:
  type: rabbitmq:3.8
  disk: 2048

  2. Aggiornare il file di configurazione .magento.app.yaml.

    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. Richiedi una nuova istanza Redis dedicata alle sessioni sugli ambienti di produzione e staging.

    Invia un ticket di supporto Adobe Commerce. Includere i file di configurazione .magento/services.yaml e .magento.app.yaml aggiornati.

    Questo aggiornamento non causa tempi di inattività, ma richiede una distribuzione per attivare il nuovo servizio.

  4. Verifica che la nuova istanza sia in esecuzione e annota il numero della porta.

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

  5. Aggiungere il numero di porta al file di configurazione .magento.env.yaml.

    note important
    IMPORTANT
    Configurare la porta di sessione Redis solo se ece-tools non è in grado di rilevarla automaticamente dalla definizione del servizio di sessione Redis MAGENTO_CLOUD_RELATIONSHIPS.
    note note
    NOTE
    Impostare disable_locking su 1 per ottenere prestazioni ottimali. Nei rari casi in cui si verificano condizioni di tipo "race condition" a causa di un'elevata attività della sessione simultanea, impostarla su 0 per abilitare il blocco.
    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. Rimuovere le sessioni dal database predefinito (db 0) nell'istanza della cache Redis.

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

  1. Aggiornare il file di configurazione .magento/services.yaml.

    code language-yaml 
    mysql:
  type: mysql:10.4
  disk: 35000

valkey:
  type: valkey:8.0

valkey-session: # This is for the new Valkey instance
  type: valkey:8.0

search:
  type: elasticsearch:7.9
  disk: 5000

rabbitmq:
  type: rabbitmq:3.8
  disk: 2048

  2. Aggiornare il file di configurazione .magento.app.yaml.

    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. Richiedi una nuova istanza di Valkey dedicata alle sessioni sugli ambienti di produzione e staging.

    Invia un ticket di supporto Adobe Commerce. Includere i file di configurazione .magento/services.yaml e .magento.app.yaml aggiornati.

    Questo aggiornamento non causa tempi di inattività, ma richiede una distribuzione per attivare il nuovo servizio.

  4. Verifica che la nuova istanza sia in esecuzione e annota il numero della porta.

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

  5. Aggiungere il numero di porta al file di configurazione .magento.env.yaml.

    note important
    IMPORTANT
    Configurare la porta di sessione Valkey solo se ece-tools non è in grado di rilevarla automaticamente dalla definizione del servizio di sessione Valkey MAGENTO_CLOUD_RELATIONSHIPS.
    note note
    NOTE
    Impostare disable_locking su 1 per ottenere prestazioni ottimali. Nei rari casi in cui si verificano condizioni di tipo "race condition" a causa di un'elevata attività della sessione simultanea, impostarla su 0 per abilitare il blocco.
    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. Rimuovere le sessioni dal database predefinito (db 0) nell'istanza della cache di Valkey.

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

Compressione cache

Se si utilizzano più di 6 GB di Redis o Valkey maxmemory, è possibile abilitare la compressione della cache per ridurre lo spazio utilizzato dalle chiavi. Tieni presente che questa impostazione consente di risparmiare memoria grazie alle prestazioni lato client. Se disponi di una capacità CPU di riserva, puoi attivarla. Vedere Utilizzare Redis per l'archiviazione della sessione o Utilizzare Valkey per l'archiviazione della sessione nella Guida alla configurazione.

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%)

Abilita liberazione asincrona

Per abilitare lazyfree su Adobe Commerce nell'infrastruttura cloud, invia un ticket di supporto Adobe Commerce richiedendo che la seguente configurazione Redis o Valkey venga applicata agli ambienti:

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

Quando lazyfree è abilitato, Redis o Valkey scarica il recupero della memoria in thread in background per eliminazioni, scadenze, eliminazioni avviate dal server, eliminazioni da parte dell'utente e scaricamenti del set di dati di replica. Questo riduce il blocco del thread principale e può ridurre la latenza della richiesta.

NOTE
Con l'opzione lazyfree-lazy-user-del yes il comando DEL si comporta come UNLINK, che scollega immediatamente le chiavi e libera la memoria in modo asincrono.
WARNING
Poiché la liberazione si verifica in background, la memoria utilizzata dalle chiavi eliminate, scadute o eliminate rimane allocata fino al completamento del lavoro da parte dei thread in background. Se l’istanza Redis o Valkey è già soggetta a una forte pressione di memoria, esegui il test con cautela e valuta prima di tutto la riduzione della pressione di memoria. Ad esempio, disattiva la cache di blocco per casi specifici e istanze Redis di cache e sessione separate come descritto sopra.

Abilita I/O multithread

Per abilitare il threading di I/O Redis su Adobe Commerce nell'infrastruttura cloud, invia un ticket di supporto Adobe Commerce richiedendo la configurazione del threading di I/O seguente. Questa configurazione può migliorare il throughput scaricando le letture e le scritture del socket e l'analisi dei comandi dal thread principale, al costo di un maggiore utilizzo di CPU. Convalida sotto carico e monitora gli host.

Configurare i thread di I/O per Redis

Per 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.
Configurazione thread di I/O per Valkey

Per Valkey:

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
events-per-io-thread 2
NOTE
I thread di I/O sono paralleli solo all'I/O client e all'analisi. L’esecuzione del comando Redis rimane a thread singolo.
WARNING
L'abilitazione dei thread di I/O può aumentare l'utilizzo di CPU e non giovare a tutti i carichi di lavoro. Inizia con un valore e un benchmark prudenti. Se la latenza aumenta o CPU satura, ridurre io-threads o disabilitare le letture nei thread di I/O.

Aumentare i timeout e i tentativi client

Aumentare la tolleranza del client cache Redis o Valkey a brevi periodi di saturazione regolando le opzioni di back-end in .magento.env.yaml.

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

Queste impostazioni possono ridurre gli errori di connessione intermittente e di timeout di lettura durante picchi brevi, ritentando la configurazione della connessione e lasciando più tempo per le risposte da Redis o Valkey.

NOTE
Queste impostazioni possono essere utili in caso di breve congestione, ma non correggono il sovraccarico persistente.

Esempi di configurazione

Utilizza gli esempi seguenti come punto di partenza per le configurazioni del servizio Redis o Valkey.

Applica tutte le raccomandazioni sulle best practice

Redis
code language-yaml 
stage:
  deploy:
    MYSQL_USE_SLAVE_CONNECTION: true
    REDIS_USE_SLAVE_CONNECTION: true # Enables the slave 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
Esempio di configurazione Valkey
code language-yaml 
stage:
  deploy:
    MYSQL_USE_SLAVE_CONNECTION: true
    VALKEY_USE_SLAVE_CONNECTION: true # Enables the slave connection logic in Magento. It also works in a split architecture
    VALKEY_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

Applicare tutte le raccomandazioni sulle best practice e separare la cache non aggiornata per tipo di cache

Redis
code language-yaml 
stage:
  deploy:
    MYSQL_USE_SLAVE_CONNECTION: true
    REDIS_USE_SLAVE_CONNECTION: true # Enables the slave 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 slave 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
Chiave Valvola
code language-yaml 
stage:
  deploy:
    MYSQL_USE_SLAVE_CONNECTION: true
    VALKEY_USE_SLAVE_CONNECTION: true # Enables the slave connection logic in Magento. It also works in a split architecture
    VALKEY_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 slave 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: # 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

Informazioni aggiuntive

Consulta i seguenti argomenti correlati:

recommendation-more-help
754cbbf3-3a3c-4af3-b6ce-9d34390f3a60