[On-Premises]{class="badge informative" title="Applicabile solo ai progetti Adobe Commerce on Premises."}

Configurazione della cache L2 per l’ottimizzazione delle prestazioni

Il caching L2 (a due livelli) riduce il traffico di rete tra il servizio di cache remota e l’applicazione Commerce aggiungendo un livello di cache locale su ciascun nodo web. Un’istanza Commerce standard può trasferire circa 300 KB per richiesta. Con volumi di richiesta elevati, il traffico di rete risultante può essere considerevole.

Con il caching L2, ogni nodo web memorizza localmente i dati a cui si accede di frequente e utilizza la cache remota per due scopi:

Commerce memorizza la versione con hash dei dati nella cache remota, aggiungendo il suffisso :hash alla chiave regolare. Quando la cache locale è obsoleta, i dati vengono recuperati dal servizio cache remota tramite un adattatore cache.

L’implementazione della cache L2 disponibile dipende dalla versione e dal livello di patch di Commerce:

Configurazione cache L2 RemoteSynchronizedCache

Le istruzioni di configurazione della cache dipendono dalla versione di Commerce in uso:

Per le versioni locali di Adobe Commerce che supportano Redis, utilizzare l’esempio seguente per modificare o sostituire la sezione cache esistente nel file app/etc/env.php.

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

Dove:

Per le versioni di Adobe Commerce precedenti alla 2.4.9 che supportano Redis o Valkey, Adobe consiglia di utilizzare Redis o Valkey per il caching remoto, come supportato dalla versione esatta, e Cm_Cache_Backend_File per il caching locale. La cache locale viene comunemente archiviata in un file system temporaneo, ad esempio /dev/shm/:

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

Adobe consiglia di utilizzare la funzione [cache preload](redis-pg-cache.md#redis-preload-feature), in quanto riduce il carico su Redis. Assicurarsi di aggiungere il suffisso :hash per le chiavi di precaricamento.

Opzioni cache non aggiornate

A partire da Commerce 2.4, l’opzione use_stale_cache può migliorare le prestazioni in casi specifici fornendo i dati precedentemente memorizzati nella cache mentre i nuovi dati della cache vengono generati in un processo parallelo. I tipi di cache consigliati e i compromessi descritti in questa sezione si applicano sia alle implementazioni RemoteSynchronizedCache che a quelle symfony_l2. Per un esempio di configurazione di symfony_l2, vedere Cache L2 Symfony con cache non aggiornata.

In genere, il compromesso con l’attesa di blocco è accettabile dal punto di vista delle prestazioni. Tuttavia, con l’aumento del numero di blocchi o voci della cache, le attese dei blocchi richiedono più tempo. In alcuni scenari, l’attesa può essere pari a il numero di chiavi x timeout ricerca per il processo. In rari casi, un utente può avere centinaia di chiavi nella cache Block/Config, quindi anche un piccolo timeout di ricerca per un blocco può costare secondi.

Adobe consiglia di abilitare l’opzione use_stale_cache solo per i tipi di cache che ne beneficiano maggiormente, tra cui:

Adobe sconsiglia di abilitare l’opzione use_stale_cache per il tipo di cache default.

Il codice seguente mostra un esempio di configurazione per il backend RemoteSynchronizedCache. Per un esempio di symfony_l2, vedere Cache L2 Symfony con cache non aggiornata.

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

Implementazione della cache L2 di Symfony

Nelle versioni di Commerce 2.4.9+, utilizza l’implementazione della cache L2 di Symfony (symfony_l2 backend) invece di RemoteSynchronizedCache. La cache L2 di Symfony fornisce un’implementazione di caching conforme a PSR-6 utilizzando Valkey.

Migrazione da RemoteSynchronizedCache a Symfony L2

Se si sta aggiornando un’installazione locale dal backend RemoteSynchronizedCache a symfony_l2, controllare quanto segue prima di aggiornare app/etc/env.php. La modifica solo del valore backend non è sufficiente. La struttura della configurazione, i nomi delle chiavi e alcuni comportamenti predefiniti sono diversi.

Esempio di configurazione con cache L2 Symfony

Nel file app/etc/env.php, utilizzare il tipo di back-end symfony_l2 semplificato per la cache L2. Questo esempio non include la configurazione preload_keys, che non è consigliata con symfony_l2. Per ulteriori dettagli, vedere Migrazione da RemoteSynchronizedCache a Symfony L2.

L’esempio imposta cleanup_percentage su 90. Il valore predefinito è 95. Regola questo valore in base allo storage della cache locale disponibile e ai requisiti della distribuzione Commerce.

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

Cache Symfony L2 con cache non aggiornata

Vedi Opzioni cache non aggiornata per le quali i tipi di cache beneficiano di una cache non aggiornata e perché.

Utilizzare l’esempio seguente per configurare front-end separati per il supporto cache non aggiornata symfony_l2:

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

Opzioni di back-end per la cache L2 di Symfony

Prestazioni e affidabilità migliorate della cache L2 di Symfony

Gli aggiornamenti più recenti migliorano la scalabilità della cache di Symfony L2, riducono gli I/O inutili dei file system e migliorano la coerenza e l’affidabilità della cache.

Memorizzazione tag cache L2 ottimizzata di Symfony

Per le distribuzioni della cache Symfony L2 con supporto Valkey, i tag della cache sono memorizzati esclusivamente in Valkey. In questo modo si eliminano le scritture ridondanti dell’indice dei tag del file system, si riducono le operazioni di I/O del disco e si evita la crescita inutile della directory var/cache/symfony/tags/.

Miglioramento del comportamento della cache basata su file

Per le distribuzioni che utilizzano la cache basata su file (senza Valkey), l’indice dei tag locali continua a essere mantenuto per supportare l’invalidamento della cache. L’indice dei tag viene ora scritto nel percorso cache_dir configurato anziché nel percorso var/cache codificato in precedenza, garantendo un utilizzo coerente della directory della cache e un supporto migliorato per le configurazioni della cache personalizzata.

Correzione dell’appartenenza ai tag obsoleti dopo il retagging

Il retagging di una voce della cache può lasciarla associata a tag a cui non appartiene più. Le appartenenze ai tag non aggiornate vengono ora cancellate al momento del retag, pertanto le voci della cache vengono invalidate solo dai tag attualmente assegnati.

Correzione di scrittura remota ridondante per salvataggi invariati

Il salvataggio di una voce della cache con contenuto invariato attivava ancora una scrittura sul backend remoto (Valkey). I salvataggi ora vengono ignorati quando il contenuto non viene modificato, riducendo le scritture remote non necessarie.

Correzione sfratto basata sulle dimensioni L1 (cleanup_percentage)

La soglia cleanup_percentage utilizzata per l’eliminazione basata sulle dimensioni L1 non ha attivato in modo coerente la pulizia. L’eliminazione della cache L1 ora rispetta correttamente cleanup_percentage configurato.

Blocco di rigenerazione per cache non aggiornata

Quando use_stale_cache è abilitato e la copia remota di una voce non è temporaneamente disponibile, solo un processo acquisisce un blocco di breve durata per rigenerare la voce. Altre richieste simultanee per la stessa voce continuano a fornire il valore locale esistente invece di rigenerarlo personalmente, riducendo gli stamp di rigenerazione e il carico di back-end ridondante.

Impatto

Per opzioni di configurazione dettagliate, vedi: