Cena clássica. O deploy terminou sem erro, o arquivo novo está no servidor, você já rodou cache:flush duas vezes, limpou o Varnish, apagou generated — e a loja continua com o comportamento antigo. Some o navegador anônimo e continua igual.
Quando chega nesse ponto, o cache que sobrou é o do próprio PHP. E ele não tem nada a ver com o Magento.
Os valores que a Adobe recomenda
Estão na página de boas práticas de performance do próprio Adobe Commerce:
| Diretiva | Valor | Para quê |
|---|---|---|
opcache.memory_consumption | 512 | MB de memória compartilhada; cabe o Magento mais as extensões |
opcache.max_accelerated_files | 60000 | quantidade de arquivos guardados |
opcache.consistency_checks | 0 | desliga verificação que custa CPU sem trazer nada em produção |
opcache.validate_timestamps | 0 | para de olhar a data de modificação dos arquivos |
opcache.enable_cli | 1 | vale para os comandos do bin/magento |
realpath_cache_size | 10M | cache de resolução de caminho, fora do OPcache |
realpath_cache_ttl | 7200 | tempo de vida desse cache, em segundos |
Dois detalhes que valem saber.
O max_accelerated_files não é usado literalmente: o PHP arredonda para o primeiro número de uma lista fixa de primos que seja maior ou igual ao seu valor. Pedindo 60000 você recebe 65407 na prática.
E tem um que a Adobe pede em outra página, a de pré-requisitos de PHP: opcache.save_comments precisa valer 1. Parece detalhe de documentação e não é — o Magento lê anotação de docblock para resolver injeção de dependência. Com os comentários descartados, a loja quebra de um jeito que não parece ter relação nenhuma com OPcache.
Por que o deploy some com validate_timestamps=0
O manual do PHP é direto: quando essa diretiva está desligada, you must reset OPcache manually via opcache_reset(), opcache_invalidate() or by restarting the Web server for changes to the filesystem to take effect.
Traduzindo para a sua sexta-feira: o php-fpm guardou a versão compilada de cada arquivo na memória e não vai mais conferir o disco. Você pode trocar o PHP inteiro que ele continua servindo o que carregou na primeira requisição depois do último restart.
No Magento isso pega feio por causa do generated/. O setup:di:compile reescreve interceptors e factories ali, mas roda na CLI — e CLI e php-fpm têm OPcache separados, cada um na sua memória. O comando termina feliz, e o pool web segue com os interceptors velhos apontando para o código velho.
Então a última linha do deploy é sempre esta:
sudo systemctl reload php8.4-fpmTroque 8.4 pela sua versão. O reload faz reinício gracioso: os workers terminam a requisição que estão atendendo, o master recria a memória compartilhada, e ninguém leva erro. Se der qualquer dúvida, restart resolve com certeza — só que aí as requisições em voo morrem.
Não adianta chamar opcache_reset() por um php -r na linha de comando esperando limpar o pool web. Isso limpa o OPcache daquele processo, que nasce e morre no mesmo comando.
Onde configurar e como conferir
Em Debian e Ubuntu, os pacotes deixam o arquivo em:
/etc/php/8.4/fpm/conf.d/10-opcache.iniE é aqui que mora uma armadilha: existe um conf.d para o fpm e outro para o cli. Ajustar só um e achar que ajustou os dois é rotina. Descubra qual arquivo cada um lê com:
php -i | grep "Loaded Configuration File"
php -i | grep opcache.validate_timestampsIsso te dá a visão da CLI. Para saber o que o pool web está usando de verdade, o jeito honesto é ler o status pela web — um phpinfo() temporário em página protegida, ou uma ferramenta como o cachetool. Confiar no php -i para responder pelo php-fpm é o erro que faz a pessoa achar que configurou e não configurou.
Uma última, sobre desenvolvimento: em máquina local, validate_timestamps=0 é sofrimento puro — você edita o arquivo e nada muda. Lá o valor é 1, com opcache.revalidate_freq=0 para conferir a cada requisição. A configuração da Adobe é para produção, e produção é onde ninguém edita arquivo na mão.
Perguntas rápidas
Preciso mesmo de 512 MB de OPcache?
É o valor que a Adobe recomenda por caber uma instalação com bastante extensão. Se o servidor for apertado, a documentação cita 64 MB como alternativa de baixa memória, mantendo o mesmo max_accelerated_files.
O reload do php-fpm derruba a loja por um instante?
Não deveria. O reload é gracioso: os workers terminam a requisição atual antes de sair. Quem derruba conexão em voo é o restart.
Dá para deixar validate_timestamps=1 e viver em paz?
Dá, e muita loja vive assim. O custo é uma verificação de data por arquivo incluído, em toda requisição. Vale medir na sua loja antes de decidir, mas a recomendação oficial para produção continua sendo zero.
Pra conferir na fonte
- Performance best practices: software recommendations — Adobe Experience League
- Required PHP settings — Adobe Experience League
- OPcache configuration directives — PHP Manual
- System requirements (versões de PHP suportadas) — Adobe Experience League