[No local]{class="badge informative" title="Aplicável somente a projetos do Adobe Commerce no local."}

Configuração do cache L2 para otimização do desempenho

O cache L2 (de dois níveis) reduz o tráfego de rede entre o armazenamento remoto em cache (Redis ou Valkey) e o aplicativo Commerce, adicionando uma camada de cache local em cada nó da Web. Uma instância padrão do Commerce transfere cerca de 300 KB por solicitação, e o tráfego pode aumentar rapidamente para mais de 1000 solicitações em algumas situações.

Com o cache L2, cada nó da Web armazena os dados acessados com frequência localmente e usa o cache remoto para duas finalidades:

O Commerce armazena a versão de dados com hash no cache remoto, com o sufixo :hash anexado à chave regular. Quando o cache local está desatualizado, os dados são obtidos da máquina remota por meio de um adaptador de cache.

Há duas implementações de cache L2 disponíveis no Adobe Commerce:

O cache L2 do Symfony é a implementação recomendada para o Adobe Commerce 2.4.9 e versões posteriores. Ele fornece uma implementação de cache moderna e compatível com PSR-6, com melhorias significativas de desempenho em relação ao RemoteSynchronizedCache tradicional.

Configuração herdada do cache L2 (RemoteSynchronizedCache)

As instruções de configuração do cache L2 herdado se aplicam às versões mais antigas do Adobe Commerce. Se você estiver na versão 2.4.9 ou posterior do Adobe Commerce, use o Valkey com a implementação do cache Modern Symfony L2.

Para versões locais do Adobe Commerce que oferecem suporte a Redis, use o exemplo a seguir para modificar ou substituir a seção de cache existente no arquivo 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'],
    ],
]

Onde:

Para versões do Adobe Commerce anteriores à 2.4.9 que oferecem suporte a Redis, a Adobe recomenda o uso de Redis para cache remoto (\Magento\Framework\Cache\Backend\Redis) e Cm_Cache_Backend_File para o cache local de dados na memória compartilhada, usando: 'local_backend_options' => ['cache_dir' => '/dev/shm/'].

A Adobe recomenda o uso do recurso cache preload, pois ele diminui drasticamente a pressão sobre o Redis. Não se esqueça de adicionar o sufixo :hash para chaves de pré-carregamento.

Opções de cache obsoletas

A partir do Commerce 2.4, a opção use_stale_cache pode melhorar o desempenho em casos específicos, disponibilizando dados armazenados em cache anteriormente enquanto novos dados de cache são gerados em um processo paralelo. Os tipos de cache recomendados e as compensações descritas nesta seção se aplicam às implementações RemoteSynchronizedCache e symfony_l2 herdadas. Para obter um exemplo de configuração symfony_l2, consulte cache L2 do Symfony com cache obsoleto.

Geralmente, a compensação com a espera por bloqueio é aceitável de uma perspectiva de desempenho. No entanto, à medida que o número de blocos ou entradas de cache aumenta, as esperas de bloqueio demoram mais tempo. Em alguns cenários, a espera pode ser de até o número de chaves x tempo limite de pesquisa para o processo. Em casos raros, um comerciante pode ter centenas de chaves no cache do Block/Config, portanto, mesmo um pequeno tempo limite de pesquisa para um bloqueio pode custar segundos.

A Adobe recomenda habilitar a opção use_stale_cache somente para os tipos de cache que mais se beneficiarem dela, incluindo:

A Adobe não recomenda habilitar a opção use_stale_cache para o tipo de cache default.

O código a seguir mostra um exemplo de configuração para o back-end herdado RemoteSynchronizedCache. Para um exemplo de symfony_l2, consulte cache L2 do Symfony com cache obsoleto.

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

Implementação do cache Modern Symfony L2

Nas versões 2.4.9+ do Commerce, use a implementação de cache L2 baseada em cache Symfony (back-end do symfony_l2) em vez do cache L2 herdado. O cache L2 do Symfony fornece uma implementação de cache moderna e compatível com PSR-6, com melhorias significativas de desempenho em relação ao RemoteSynchronizedCache tradicional.

Benefícios do cache Symfony L2

Migração de RemoteSynchronizedCache para Symfony L2

Se você estiver atualizando uma instalação local do back-end herdado RemoteSynchronizedCache para symfony_l2, revise o seguinte antes de atualizar app/etc/env.php. Não é suficiente alterar apenas o valor backend. A estrutura de configuração, os nomes de chave e alguns comportamentos padrão são diferentes.

Exemplo de configuração com o cache L2 do Symfony

No arquivo app/etc/env.php, use o tipo de back-end symfony_l2 simplificado para cache L2. Este exemplo não inclui a configuração preload_keys, que não é recomendada com symfony_l2. Para obter detalhes, consulte Migrando de RemoteSynchronizedCache para 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 com cache obsoleto

Consulte Opções de cache obsoleto para saber quais tipos de cache se beneficiam do cache obsoleto e por quê.

Use o exemplo a seguir para configurar front-ends separados para o suporte a cache obsoleto do 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'],
    ],
],

Opções de back-end para o cache do Symfony L2

Desempenho e confiabilidade aprimorados do cache Symfony L2

As atualizações mais recentes melhoram a escalabilidade do cache L2 do Symfony, reduzem a E/S desnecessária do sistema de arquivos e melhoram a consistência e a confiabilidade do cache.

Armazenamento otimizado de tags de cache do Symfony L2

Otimização do comportamento do cache do Symfony L2 para implantações com suporte da Valkey, eliminando gravações redundantes de índice de tags no sistema de arquivos. As tags de cache agora são armazenadas exclusivamente no Valkey, alinhando o comportamento do cache Symfony L2 com a implementação do cache herdado. Isso reduz a E/S de disco desnecessária, melhora o desempenho de gravação de cache e impede o crescimento do diretório var/cache/symfony/tags/.

Comportamento aprimorado do cache baseado em arquivos

Para implantações que usam o cache baseado em arquivos (sem Valkey), o índice de tag local continua sendo mantido para oferecer suporte à invalidação do cache. O índice de tag agora é gravado no cache_dir configurado, em vez do local var/cache previamente codificado, garantindo um uso consistente do diretório de cache e melhor suporte para configurações de cache personalizadas.

Correção de associação de tag obsoleta após a remarcação

A remarcação de uma entrada de cache pode deixá-la associada a tags às quais ela não pertencia mais. As associações de tag obsoletas agora são limpas na remarcação, portanto, as entradas de cache são invalidadas somente pelas tags atribuídas a elas no momento.

Correção de gravação remota redundante para salvamentos inalterados

Salvar uma entrada de cache com conteúdo inalterado ainda acionava uma gravação no back-end remoto (Valkey). Os salvamentos agora são ignorados quando o conteúdo não é alterado, reduzindo as gravações remotas desnecessárias.

Correção de remoção baseada em tamanho N1 (cleanup_percentage)

O limite cleanup_percentage usado para remoção baseada no tamanho L1 não disparou a limpeza de forma consistente. A remoção do cache L1 agora respeita corretamente o cleanup_percentage configurado.

Bloqueio de regeneração para cache obsoleto

Quando use_stale_cache está habilitado e a cópia remota de uma entrada está temporariamente indisponível, apenas um processo agora adquire um bloqueio de vida curta para regenerar essa entrada. Outras solicitações simultâneas para a mesma entrada continuam a servir o valor local existente em vez de regenerá-lo, reduzindo os carimbos de regeneração e a carga de back-end redundante.

Impacto

Para obter opções de configuração detalhadas, consulte: