OPcache et JIT en production PHP 8.3 — ce qui bouge réellement l'aiguille

OPcache de PHP 8.3 est l'un des changements de configuration au plus haut ROI dans toute la stack. La config par défaut est dev-friendly (revalidation fréquente, mémoire modeste). La config correcte en production est un petit changement qui coupe régulièrement l'usage CPU de 30-40 % sur les charges Laravel et WordPress. JIT est le frère plus trouble — parfois une victoire claire, parfois neutre, occasionnellement une régression.

Voici ce que nous livrons et pourquoi.

La config production

opcache.enable=1
opcache.memory_consumption=512
opcache.interned_strings_buffer=32
opcache.max_accelerated_files=20000
opcache.validate_timestamps=0
opcache.revalidate_freq=0
opcache.save_comments=1
opcache.fast_shutdown=1
opcache.jit_buffer_size=128M
opcache.jit=tracing

Le flag à plus fort impact est validate_timestamps=0. Il dit à OPcache de ne jamais vérifier si un fichier a changé — il fait simplement confiance à ce qui est dans le cache. Trade-off : les déploiements nécessitent un opcache_reset() explicite ou un reload PHP-FPM, ce que votre pipeline de déploiement devrait faire de toute façon.

L'article complet couvre :

• Pourquoi validate_timestamps=0 a sa place dans chaque config production
• Dimensionner memory_consumption et max_accelerated_files pour votre codebase
• Modes JIT (function, tracing) — et les charges où chacun aide
• Quand JIT fait réellement mal (PHP-comme-templating, charges majoritairement I/O)
• Lire la sortie de opcache_get_status() pour vérifier qu'il fait son job
• Stratégies de cold-start pour containers éphémères (preloading vs lazy)

Nous livrons cette configuration sur chaque install PHP managée.