Como configurar OPcache no PHP em produção pra ganhar performance

OPcache é a extensão de cache de bytecode embutida no PHP desde a versão 5.5. Sem ele, o PHP lê, parseia e compila cada arquivo .php em cada requisição — trabalho que se repete milhões de vezes ao dia em produção. Com OPcache habilitado e bem configurado, o bytecode compilado vive em memória compartilhada e cada request reaproveita o resultado, cortando latência e uso de CPU de forma significativa.

Este tutorial é pra desenvolvedores PHP que rodam aplicações em produção (Laravel, Symfony, WordPress, ou código próprio) e ainda não habilitaram OPcache, ou habilitaram com configuração default e não sabem se está bem dimensionado. Tempo estimado de execução: 20-30 minutos, incluindo a parte de medição e ajuste.

O foco é prático: parâmetros que importam, valores razoáveis pra começar, como verificar que o cache está sendo usado de verdade e como invalidar bytecode após deploy sem derrubar PHP-FPM. Tudo testado em PHP 8.3 sobre Ubuntu 24.04 LTS, mas os princípios valem pra qualquer versão 7.4+ em qualquer distribuição.

Pré-requisitos

Confirme que o OPcache está disponível antes de configurar. Se o comando abaixo não listar opcache, você precisa instalar o pacote php-opcache (Debian/Ubuntu) ou php-opcache (RHEL/Alma/Rocky).

php -m | grep -i opcache

Se a saída for Zend OPcache, está disponível e só falta habilitar e ajustar. Se vier vazio, instale primeiro.

Verificar o estado atual

Antes de mudar qualquer parâmetro, registre como o OPcache está agora. Isso vira sua linha de base pra comparar depois.

php --ri opcache

<?php
header('Content-Type: application/json');
echo json_encode(opcache_get_status(false), JSON_PRETTY_PRINT);

curl http://127.0.0.1/opcache-status.php | head -30

Configuração recomendada

Crie ou edite o arquivo de configuração específico do OPcache. Em Ubuntu/Debian fica em /etc/php/8.3/fpm/conf.d/10-opcache.ini (ajuste a versão).

sudo nano /etc/php/8.3/fpm/conf.d/10-opcache.ini

zend_extension=opcache.so

opcache.enable=1
opcache.enable_cli=0

opcache.memory_consumption=256
opcache.interned_strings_buffer=16
opcache.max_accelerated_files=20000

opcache.validate_timestamps=1
opcache.revalidate_freq=60

opcache.save_comments=1
opcache.fast_shutdown=1
opcache.huge_code_pages=0

opcache.max_wasted_percentage=10
opcache.consistency_checks=0

Referência dos parâmetros principais:

sudo systemctl restart php8.3-fpm

Dimensionar memory_consumption corretamente

256 MB é um ponto de partida razoável, mas a memória ideal depende do tamanho do seu codebase. Aplicação Laravel típica com vendor/ completo consome 80-150 MB. WordPress com 30 plugins pode passar de 200 MB.

php -r 'print_r(opcache_get_status(false)["memory_usage"]);'

Array
(
    [used_memory] => 142336512
    [free_memory] => 125829120
    [wasted_memory] => 0
    [current_wasted_percentage] => 0
)

Estratégia de deploy: invalidar o cache

Com validate_timestamps=1 e revalidate_freq=60, mudanças em arquivos PHP só são detectadas após 60 segundos. Pra deploys atômicos, isso é insuficiente — você precisa invalidar o cache no momento do deploy.

curl -sO https://gordalina.github.io/cachetool/downloads/cachetool.phar
chmod +x cachetool.phar
sudo mv cachetool.phar /usr/local/bin/cachetool

cachetool opcache:reset --fcgi=/var/run/php/php8.3-fpm.sock

Verificar o ganho real

Configurar sem medir é fé, não engenharia. Compare latência e CPU antes e depois.

ab -n 1000 -c 10 https://seudominio.com/api/produtos

php -r 'print_r(opcache_get_status(false)["opcache_statistics"]);'

Resolução de problemas

Cache fica cheio rápido e wasted_memory dispara

Sinal de que max_accelerated_files está baixo ou que max_wasted_percentage foi atingido. O OPcache começa a descartar entradas e refragmenta a memória. Aumente max_accelerated_files pra 30000-50000 e memory_consumption em 50%.

opcache_get_status() retorna false em scripts CLI

Default seguro: opcache.enable_cli=0 desabilita OPcache no CLI. Se você precisa inspecionar via CLI, suba pra 1 temporariamente. Em produção, mantenha 0 — scripts CLI são curtos e cache não ajuda.

Mudanças no código não aparecem após deploy

Ou validate_timestamps=0 sem reset programático, ou cache de outro tipo (Redis/file cache da aplicação) está servindo dados antigos. Rode cachetool opcache:reset e limpe cache de aplicação (php artisan cache:clear no Laravel, por exemplo).

Próximos passos

Depois que OPcache estiver estável, o próximo ganho costuma vir de tunar PHP-FPM (pool size, pm.max_children) pra acompanhar o throughput maior que o servidor consegue agora. Vale também avaliar OPcache JIT em apps com componente CPU-intensivo e revisar headers de cache HTTP no nginx pra reduzir ainda mais a pressão no PHP.

Se você está rodando em hardware compartilhado e o ganho de performance vira limite de recursos do plano, uma VPS Hostini com KVM dedicado dá controle total sobre PHP-FPM, memória do OPcache e parâmetros de kernel — sem disputa de CPU com vizinhos barulhentos.