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

Configurazione della cache L2 per l’ottimizzazione delle prestazioni

La memorizzazione nella cache L2 (a due livelli) riduce il traffico di rete tra lo storage della cache remota (Redis o Valkey) e l’applicazione Commerce aggiungendo un livello di cache locale su ciascun nodo web. Un’istanza Commerce standard trasferisce circa 300 KB per richiesta e in alcune situazioni il traffico può superare rapidamente le 1000 richieste.

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 non è aggiornata, i dati vengono recuperati dal computer remoto tramite un adattatore cache.

In Adobe Commerce sono disponibili due implementazioni di cache L2:

La cache L2 di Symfony è l’implementazione consigliata per Adobe Commerce 2.4.9 e versioni successive. Fornisce un’implementazione di caching moderna e conforme a PSR-6 con miglioramenti significativi delle prestazioni rispetto al tradizionale RemoteSynchronizedCache.

Configurazione cache L2 legacy (RemoteSynchronizedCache)

Le istruzioni di configurazione della cache L2 legacy si applicano alle versioni precedenti di Adobe Commerce. Se utilizzi Adobe Commerce versione 2.4.9 o successiva, utilizza Valkey con implementazione della cache L2 Modern Symfony.

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, Adobe consiglia di utilizzare Redis per il caching remoto (\Magento\Framework\Cache\Backend\Redis) e Cm_Cache_Backend_File per il caching locale dei dati nella memoria condivisa, utilizzando: 'local_backend_options' => ['cache_dir' => '/dev/shm/'].

Adobe consiglia di utilizzare la funzionalità cache preload, in quanto riduce drasticamente la pressione su Redis. Non dimenticare 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 legacy RemoteSynchronizedCache che a quelle legacy 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 commerciante 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 legacy 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 moderna della cache L2 di Symfony

Nelle versioni di Commerce 2.4.9+, utilizzare l’implementazione della cache L2 basata su Symfony Cache (symfony_l2 backend) invece della cache L2 legacy. La cache L2 di Symfony fornisce un’implementazione di caching moderna e conforme a PSR-6 con miglioramenti significativi delle prestazioni rispetto alla tradizionale RemoteSynchronizedCache.

Vantaggi della cache L2 di Symfony

Migrazione da RemoteSynchronizedCache a Symfony L2

Se si sta aggiornando un’installazione locale dal back-end legacy 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.

'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

È stato ottimizzato il comportamento della cache L2 di Symfony per le distribuzioni con supporto Valkey, eliminando le scritture ridondanti dell’indice dei tag del file system. I tag cache sono ora memorizzati esclusivamente in Valkey, allineando il comportamento della cache di Symfony L2 con l’implementazione della cache legacy. In questo modo si riduce l’I/O del disco non necessario, si migliorano le prestazioni di scrittura della cache e si impedisce la crescita 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 poteva lasciarla associata a tag a cui non apparteneva 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: