Inspeção de cache automático do Magento

Estamos executando o Magento EE 1.11 com memcache. 2 GB por servidor de memória, total de 4 GB. Temos cerca de 240k produtos.

• RAM disponível: 6GB
• Cores: 16
• Tópicos: 32

Aqui está o acordo, mais novos produtos são adicionados e alterações nos produtos ocorrem diariamente e, é claro, sempre que um novo produto é adicionado / modificado no back-end, o cache é invalidado, especificamente o 'Cache de página inteira'.

Quando a Geração automática de cache do Magentos está ativada, leva cerca de 2 dias para criar o cache, com 8 threads alocados ao rastreador. Após 2 dias, o memcache flutua em torno de 2 GB separados entre os dois discos ram.

O problema é que, quando os produtos são modificados diariamente, o cache é invalidado e, assim que o 'Full Page Cache' é atualizado, os 2 GB de cache retornam à estaca zero, 0, e o ciclo viscoso do cache do Magentos Auto é iniciado novamente. Agora, o cache não volta apenas a 0, mas o uso da CPU aumenta para 90% e o site se transforma em um jogo de espera de 5 a 10 segundos e você pode esquecer de tentar solicitar um produto com mais de 100 variações, se for não armazenado em cache, levaria alguns minutos para carregar pela primeira vez, é ridículo.

Então, minhas perguntas para a comunidade.

• Existe uma maneira do Magento "atualizar" automaticamente o cache se for invalidado, sem reconstruir o cache inteiro e começar a partir de 0? Sei que quando o cache é invalidado, o Magento sabe que alguma coisa mudou, mas não exatamente onde está o cache (me corrija se estiver errado). Existem módulos / configurações disponíveis para ignorar a reconstrução de todo o cache?

Na nota lateral, estamos usando o módulo Tiny Bricks LightSpeed.

• A Geração Automática de Cache do Magentos pode ser controlada por tempo com um cronjob? Digamos, para começar a rastrear às 22h - 6h.

• Qual seria a melhor maneira de abordar essa situação ?, Como você entende que reconstruir um cache com gigabytes todos os dias não é aceitável.

Você não tem RAM suficiente

Temos cerca de 240k produtos
RAM disponível: 6GB
Threads: 32

Você não tem RAM suficiente para a quantidade de produtos que possui. Como regra geral, recomendamos pelo menos 2-4 GB de RAM por núcleo lógico.

Se você mapear seu possível uso de memória:

• 64 threads em PHP com max_memory~ 768MB = 24GB
• 240.000 produtos provavelmente significarão cerca de 15 GB de espaço de tabela InnoDB
• 64 PHP Threads garantirão cerca de 128 conexões MySQL, normalmente com um custo de aproximadamente 200 MB por conexão, no mínimo
• O armazenamento de back-end para 240.000 produtos em Redis E lzfcompactado - ainda consumirá cerca de 6 GB de RAM

Portanto, o total até agora é de 70 GB de RAM comprometida - nem mencionamos o sistema operacional etc.

Seu hardware está terrivelmente subespecificado . Eu sugeriria a leitura deste artigo de configuração do servidor Magento para saber como progredir.

Memcached não suporta tags de cache

Se você estiver usando o Memcached (não é um problema, seu desempenho é muito alto), então você está armazenando tags de cache ou não. Se você não tiver slow_backenddefinido - não estará armazenando tags, o que basicamente significa que seu cache não pode discriminar nenhum dos diferentes tipos de cache - para que você não possa liberá-los independentemente.

Leia sobre isso, http://www.sonassi.com/knowledge-base/magento-kb/what-is-memcache-actually-caching-in-magento/

Sugerimos enfaticamente a mudança para Redis. Ele tem suas peculiaridades e precisa de ajustes significativos para lojas maiores. Mas, como um todo, terá um desempenho um pouco melhor que o Memcached, com o benefício real do suporte a tags de cache.

404 e FPC

O FPC tem um problema real; de fato, todos os mecanismos de cache têm um problema com os 404s. O motivo é que qualquer URL antigo ainda sendo rastreado ou vinculado será direcionado para uma página que precisa percorrer toda a core_url_rewritetabela, tente encontrar uma correspondência com todos os roteadores e espaços de nome definidos antes de finalmente desistir e carregar um 404.

Em seguida, coloque em cache um recurso que não tem valor e consumirá espaço no seu armazenamento em cache. Você provavelmente encontrará uma grande proporção do seu armazenamento Memcached sendo consumido pelo conteúdo 404.

Com grandes catálogos (produtos de 240k), você certamente terá sua parcela justa de rotatividade de produtos e, portanto, alterações nos URLs e, posteriormente, muitos 404s.

Invalidar FPC vs. Limpar

No momento - e por padrão - o comportamento do FPC é limpar o cache nas alterações, em vez de apenas invalidar a entrada do cache. Escrevemos uma extensão para alterar esse comportamento para que um armazenamento EE faça exatamente o que você precisa.

Aqui está um patch rápido para você ter uma idéia de como resolver seu problema.

app/code/core/Enterprise/PageCache/etc/config.xml
index 6a56a80..85ebc92 100644
--- app/code/core/Enterprise/PageCache/etc/config.xml
+++ app/code/core/Enterprise/PageCache/etc/config.xml
@@ -139,7 +139,7 @@
             <observers>
                 <enterprise_pagecache>
                     <class>enterprise_pagecache/observer</class>
-                    <method>cleanCache</method>
+                    <method>invalidateCache</method>
                 </enterprise_pagecache>
             </observers>
         </catalogrule_after_apply>

Não execute um rastreador

Se você tem uma base suficiente decente - não recomendamos executar a ferramenta de rastreamento, ela gera carga desnecessária. As pessoas / bots / rastreadores que navegam no site devem manter o cache preparado.

Mas, para responder à sua pergunta, se você procurar no arquivo de configuração mencionado acima - verá a programação do cron que foi definida para a janela de navegação de rastreamento.

Se você puder comprar conteúdo obsoleto

E, finalmente, se você tiver RAM suficiente . Você pode se beneficiar do aumento do TTL do conteúdo armazenado no FPC - para manter seus dados em cache ativos por mais tempo.

Na <full_page_cache>tag em seu ./app/etc/local.xmlapenas defina

<lifetimelimit>86400</lifetimelimit>

A vida útil é definida em segundos. Você precisa encontrar um equilíbrio entre a atualização do conteúdo, o desempenho e a quantidade de espaço de armazenamento que você realmente tem disponível.

Por que você está usando uma extensão de cache de terceiros com o EE

Você está pagando um prêmio pelo FPC - o que me custa dizer, é muito bom. Então, por que você está executando alternativas de terceiros por cima? Remova.

Põe desta forma. Se o seu carro estava com problemas - basta adicionar outro motor na bota para compensar; ou apenas consertar o motor já aí?

Entendemos você muito bem! Adicionamos novos ou alteramos nossos produtos todos os dias e também modificamos blocos estáticos. Então, nós estávamos cheios de cache Magento inválido e essa constante indo para Sistema -> Gerenciamento de cache. Odiamos a necessidade de atualizar os tipos de cache invalidados manualmente.

Em seguida, instalamos a nova extensão Magento Optimizer . Este módulo automatiza esse processo. Ele atualiza todos os tipos de cache invalidados / ou libera o armazenamento em cache do Magento na frequência especificada. Foi um verdadeiro alívio para toda a nossa equipe!

Mais um ótimo recurso dessa extensão é que ele limpa os arquivos de sessão e os relatórios de erros com mais de X dias. Todo mundo sabe que o tamanho dos diretórios var / session e var / report pode crescer em gigabytes e o número desses arquivos pode exceder cem. Então agora para diminuir o desempenho do site, definimos o Magento Optimizer uma vez e esquecemos a atualização periódica desses diretórios.

O Magento é conhecido por mesclar um carrinho abandonado com o atual quando os clientes tentam fazer login. Da experiência dos clientes e do ponto de vista da lealdade, é destrutivo. O módulo Magento Optimizer exclui automaticamente os carros abandonados mais antigos que X dias. Você também pode usar esse recurso no tempo de vendas e limitar o tempo para os carros abandonados existentes.