Black Friday no Magento 2: Varnish, Valkey, cron e indexadores um mês antes

Varnish: taxa de acerto e objeto expulso antes do TTL

Com o Varnish rodando há alguns dias sem reinício, peça quatro contadores:

varnishstat -1 -f MAIN.cache_hit -f MAIN.cache_miss -f MAIN.n_lru_nuked -f MAIN.n_object

A taxa de acerto é cache_hit / (cache_hit + cache_miss). Não há um número certo para toda loja: compare com a mesma conta feita num fim de semana de venda forte. Se ela cai quando o tráfego sobe, o PHP está gerando página justamente quando tem menos folga.

O contador que mais revela é o n_lru_nuked, que a documentação do Varnish define como os objetos removidos à força do storage para abrir espaço para um novo. Se ele sobe entre duas leituras, o storage está pequeno, e página ainda dentro do TTL (86400 segundos no padrão do Magento) volta para o PHP-FPM na visita seguinte. O tamanho está no parâmetro -s do varnishd:

systemctl cat varnish | grep -o -- '-s [^ ]*'

Ao aumentar o malloc, deixe RAM livre: a documentação avisa que, por fragmentação, o uso real pode chegar a duas a quatro vezes o valor configurado. Antes disso, confira se as páginas entram no cache, com a dica do cacheable=false.

Valkey ou Redis: memória, política e chave despejada

Rode nas duas instâncias, a do cache e a da sessão. Se ainda são uma só, comece pela dica dos bancos separados.

valkey-cli INFO memory | grep -E '^(used_memory_human|maxmemory_human|maxmemory_policy):'
valkey-cli INFO stats | grep -E '^(evicted_keys|keyspace_hits|keyspace_misses):'

No Redis, use redis-cli; os campos têm o mesmo nome.

• maxmemory em 0 quer dizer sem limite. Aí quem segura o crescimento é a RAM do servidor, dividida com o PHP-FPM e, muitas vezes, com o banco.
• evicted_keys conta as chaves removidas pelo limite de memória. No cache, cada uma vira PHP gerando de novo; na sessão, é cliente perdendo login e carrinho.
• maxmemory_policy em noeviction faz o oposto: com a memória cheia, valores novos deixam de ser gravados e o Magento recebe erro na escrita.

Limite e política valem para a instância inteira, e não para cada número de banco. Se você pretende sair do Redis para o Valkey, a janela é esta, com a dica da migração para o Valkey. Em novembro, eu não faria essa troca.

Cron: quanto cada job atrasa e quanto demora

Com a retenção de fábrica, a cron_schedule guarda cerca de uma hora de histórico de sucesso, o suficiente para medir cada job:

SELECT job_code,
       COUNT(*) AS execucoes,
       MAX(TIMESTAMPDIFF(SECOND, scheduled_at, executed_at)) AS atraso_max_s,
       MAX(TIMESTAMPDIFF(SECOND, executed_at, finished_at)) AS duracao_max_s
FROM cron_schedule
WHERE status = 'success'
GROUP BY job_code
ORDER BY atraso_max_s DESC
LIMIT 15;

Rode no horário de mais movimento do dia. Atraso de minutos nos jobs do grupo index, como indexer_update_all_views, é preço e estoque chegando atrasados na vitrine. Conte também o que nem chegou a rodar:

SELECT status, COUNT(*) FROM cron_schedule GROUP BY status;

Linha com missed é job que não começou dentro do schedule_lifetime do grupo: de fábrica, 15 minutos no default e 2 no index. Se o cron nem está rodando, a dica do cron parado vem primeiro.

Indexadores: tudo em schedule e backlog que volta a zero

O indexer:status mostra o modo e a fila de cada indexador:

php bin/magento indexer:status

Na coluna Update On, quero Schedule em todos. Na Schedule Status aparece algo como idle (0 in backlog). Rode algumas vezes num dia movimentado: o backlog sobe com importação de preço ou estoque e precisa voltar para perto de zero. Backlog que só cresce é o cron do grupo index sem dar conta.

Indexador ainda em Save muda agora, informando os que faltam:

php bin/magento indexer:set-mode schedule catalog_product_price catalogrule_rule

A Adobe recomenda fazer essa troca com a loja em manutenção e o cron parado, para não travar o banco, e por isso eu faço numa madrugada de outubro. Antes do 2.4.8, o customer_grid fica em realtime, porque a documentação diz que ele só funciona em Update on Save nessas versões. Os cuidados com as tabelas _cl que a troca cria estão na dica das tabelas _cl, e reprocessar um índice só está na dica do reindex específico.

O calendário que eu sigo até o dia 27

• Até 31/10: as quatro medições acima e as trocas que elas pedirem, como tamanho do storage do Varnish, memória e política do Valkey, migração do Redis e modo dos indexadores.
• De 01/11 a 15/11: nenhuma troca nova de infraestrutura. Repita as medições uma vez por semana e compare com a primeira rodada.
• A partir de 16/11: só mudança de conteúdo, preço e promoção. Se o pool do PHP-FPM precisar de ajuste, que seja antes disso; o pm.max_children está na dica do 502 e 504.
• 26/11, véspera: só leitura. As mesmas medições, com a saída guardada em arquivo para comparar com o dia seguinte.