OPcache PHP : activer et vérifier l’extension dans cPanel

Table des matières :

OPcache PHP : ce que l’extension fait réellement (et ce qu’elle ne fait pas)

OPcache est un accélérateur opcode intégré au cœur de PHP via l’extension Zend OPcache. Son principe est simple : au lieu de re-parser et re-compiler vos fichiers .php à chaque requête, il stocke en mémoire partagée le bytecode généré par le compilateur Zend, puis le réutilise. Le manuel PHP le formule clairement : « OPcache improves PHP performance by storing precompiled script bytecode in shared memory, thereby removing the need for PHP to load and parse scripts on each request. » (PHP Manual, OPcache) — PHP Manual (OPcache)

Dans une stack e-commerce (PrestaShop 8/9, modules, overrides, vendor/ Symfony/Doctrine, Composer autoload, etc.), ce gain est surtout visible dès que vous sortez d’un cache HTTP complet (Varnish/CDN) ou que vous servez des pages non cachables (panier, compte, checkout, endpoints AJAX). OPcache ne met pas en cache des pages HTML : il ne remplace ni Varnish, ni un CDN, ni un cache applicatif (Redis/Memcached). Il réduit principalement le coût « interpréteur » (parsing + compilation) et amortit des milliers d’inclusions/chargements de classes qui, sur une boutique, finissent par compter.

Deux points importants à garder en tête (souvent confondus) :

OPcache = cache de bytecode : il accélère l’exécution du code PHP déjà écrit.
Il ne corrige pas une régression applicative : un N+1 SQL, un hook trop coûteux, ou une page qui fait exploser le nombre de requêtes DB restera lente — même si le CPU PHP “pur” baisse.

Enfin, ce que beaucoup de devs découvrent tard : OPcache est partagé au niveau du processus/SAPI, pas « par site ». En pratique, sur cPanel, il est généralement utilisé via PHP-FPM (ou parfois CGI/LSAPI selon l’hébergeur). Ça implique des contraintes : taille de mémoire fixe, stratégie d’invalidation (timestamps), et impossibilité fréquente de redémarrer le pool FPM si vous n’avez pas la main root. Résultat : activer OPcache sans régler ces points peut donner un faux sentiment de perf… ou provoquer des effets de bord (code “stale”, erreurs 500, cache saturé).

Spécificités cPanel : MultiPHP, PHP-FPM et la réalité des fichiers de configuration

Sur cPanel, l’activation d’OPcache se joue à deux niveaux :

1) L’extension est-elle installée/chargée par l’hébergeur ?
2) Vos directives opcache.* sont-elles appliquées au bon SAPI (FPM vs CLI) ?

C’est la source n°1 des diagnostics incohérents du type « ça marche en CLI mais pas sur le site », ou l’inverse. Le binaire CLI (php en SSH) a son php.ini et ses .ini de modules, qui ne sont pas forcément ceux de PHP-FPM (celui qui sert vos pages web).

cPanel fournit des interfaces “account-level” pour modifier des valeurs ini sans éditer les fichiers systèmes : MultiPHP Manager (choix version PHP par domaine) et MultiPHP INI Editor (édition de directives).

À noter (réalité terrain) : selon votre hébergeur, vous pouvez aussi être sur CloudLinux + PHP Selector (interface “Select PHP Version” / “Extensions”), ou sur un serveur où OPcache est compilé/packagé mais désactivé. Avant de « chercher le bouton OPcache », identifiez votre contexte :

version PHP utilisée par domaine (MultiPHP),
mode d’exécution (PHP-FPM activé ou non),
présence effective de l’extension via phpinfo() côté web.

Activer OPcache PHP dans cPanel (sans accès root)

L’activation « propre » passe par l’UI cPanel, parce qu’elle écrit au bon endroit pour votre compte (et pour le bon SAPI). Dans cPanel → Software → MultiPHP Manager, vérifiez d’abord la version PHP utilisée par le domaine concerné.

Point d’attention : changer de version PHP peut réinitialiser certaines valeurs ini (ou charger une autre arborescence de fichiers .ini). Faites donc dans cet ordre :

1) choisir la version PHP, 2) activer PHP-FPM si votre hébergeur le permet, 3) régler OPcache et vérifier côté web.

Ensuite, dans cPanel → Software → MultiPHP INI Editor, sélectionnez le domaine (ou le mode “Editor Mode” selon votre cPanel). Cherchez opcache.enable. Objectif minimal :

opcache.enable=1

Si l’interface expose un toggle « Zend OPcache » / « opcache » (cas CloudLinux / PHP Selector), cochez l’extension et sauvegardez.

Si OPcache n’apparaît nulle part, ce n’est pas un bug de cPanel : c’est souvent que l’hébergeur n’a pas installé/activé le module pour votre version PHP, et vous ne pourrez pas le forcer sans intervention serveur.

En dernier recours (hébergeur permissif), vous pouvez pousser des directives au niveau du document root via .user.ini (souvent honoré en PHP-FPM) :

; public/.user.ini ou /home/user/public_html/.user.ini selon vhost
opcache.enable=1
opcache.memory_consumption=256
opcache.max_accelerated_files=20000

Points pratiques à connaître sur .user.ini :

La prise en compte n’est pas instantanée : elle dépend de user_ini.cache_ttl (souvent 300 secondes). Donc “je modifie → je teste immédiatement” peut donner un faux négatif.
Certains environnements n’honorent pas .user.ini du tout, ou restreignent les directives modifiables.

Et attention au piège .htaccess : les directives php_value/php_flag ne fonctionnent que dans certains modes (typiquement pas en PHP-FPM classique). Si vous n’êtes pas sûr du SAPI, commencez par le vérifier (section suivante).

Vérifier que l’extension est chargée (et que le cache opère réellement)

La vérification la plus directe côté web reste un fichier temporaire phpinfo.php :

<?php phpinfo();

Chargez-le en HTTPS, cherchez un bloc “Zend OPcache” et vérifiez que Opcode Caching est Enabled. Supprimez ensuite le fichier : phpinfo() expose des informations sensibles (paths, modules, variables). Sur un site e-commerce, traitez-le comme une fuite d’inventaire.

Pour un check automatisable (et plus fiable qu’un simple “module présent”), déployez un script non public qui appelle l’API OPcache :

<?php
if (!extension_loaded('Zend OPcache')) {
  http_response_code(500);
  exit('Zend OPcache not loaded');
}
$status = opcache_get_status(false);
$config = opcache_get_configuration();
header('Content-Type: application/json');
echo json_encode([
  'opcache_enabled' => $status['opcache_enabled'] ?? null,
  'cache_full' => $status['cache_full'] ?? null,
  'hits' => $status['opcache_statistics']['hits'] ?? null,
  'misses' => $status['opcache_statistics']['misses'] ?? null,
  'hit_rate' => $status['opcache_statistics']['opcache_hit_rate'] ?? null,
  'num_cached_scripts' => $status['opcache_statistics']['num_cached_scripts'] ?? null,
  'memory_used' => $status['memory_usage']['used_memory'] ?? null,
  'memory_free' => $status['memory_usage']['free_memory'] ?? null,
  'wasted_memory' => $status['memory_usage']['wasted_memory'] ?? null,
  'directives' => $config['directives'] ?? null,
], JSON_PRETTY_PRINT);

Référence API : opcache_get_status() manual

Interprétez les chiffres, pas juste le booléen :

cache_full=true : signe quasi certain de sous-dimensionnement (memory_consumption et/ou max_accelerated_files).
num_cached_scripts proche de la limite : vous êtes en train d’atteindre opcache.max_accelerated_files.
wasted_memory qui monte : fragmentation/évictions, souvent corrélé à des déploiements fréquents ou à une mémoire trop faible.

Sur une boutique PrestaShop, viser un hit rate élevé et stable (après warmup) est plus utile que de chercher un “record” : ce qui compte, c’est d’éviter les vagues de misses/recompilations en heures de pointe.

Cas concret (mutualisé cPanel, PHP 8.2 + FPM) : après passage de opcache.max_accelerated_files de 10000 à 20000 et memory_consumption de 128 à 256, cache_full a disparu et le TTFB médian sur pages non-cachées a baissé d’un ordre de grandeur de quelques dizaines de millisecondes, sans autre changement. Les gains varient selon CPU/IO et charge, mais le pattern “cache saturé → recompilations → CPU” est récurrent.

Paramètres OPcache recommandés en production pour une boutique PrestaShop

PrestaShop (surtout avec modules) charge beaucoup de fichiers PHP. Avant de régler à l’aveugle, comptez pour estimer l’ordre de grandeur :

cd /home/user/public_html
find . -type f -name '*.php' | wc -l

Sur des projets réels, on dépasse facilement 15k–30k fichiers (core + vendor/ + modules). Si opcache.max_accelerated_files est trop bas, OPcache n’optimise pas tout (ou doit évincer), et vous retombez dans du parsing/compiling.

Une base saine (à adapter à votre codebase et aux limites de l’hébergeur) :

opcache.enable=1
opcache.memory_consumption=256
opcache.interned_strings_buffer=16
opcache.max_accelerated_files=20000
opcache.max_wasted_percentage=10

Quelques réglages utiles à connaître (souvent oubliés), surtout en environnement e-commerce où les libs/frameworks sont nombreux :

Directive	Pourquoi c’est utile	Valeur “prudente” en prod
`opcache.save_comments`	Évite des comportements inattendus avec des libs qui lisent des docblocks (annotations/outils)	`1` (à laisser activé sauf raison)
`opcache.fast_shutdown`	Obsolète sur PHP récents, n’apporte plus grand-chose	laisser par défaut
`opcache.enable_cli`	Pratique si vous voulez bénéficier d’OPcache sur certaines tâches CLI (cron, scripts)	`0` ou `1` selon usage (mais ne confondez pas CLI/Web)

Deuxième sujet : l’invalidation. En déploiement CI/CD avec redémarrage PHP-FPM garanti, vous pouvez réduire fortement la validation de timestamps. Mais en cPanel mutualisé, vous n’avez souvent pas la main pour redémarrer proprement FPM. Donc, évitez le dogme opcache.validate_timestamps=0 si vous n’avez pas un mécanisme fiable de purge.

Recommandation pragmatique en mutualisé :

; mutualisé / pas de restart garanti
opcache.validate_timestamps=1
opcache.revalidate_freq=2

Vous payez un coût minime de vérification, mais vous évitez le scénario “déploiement OK → site sert l’ancien code pendant des heures”.

OPcache ne se traite pas isolément : il s’additionne à PHP-FPM, MySQL et caches applicatifs. Pour la vue d’ensemble (et éviter les optimisations “folklore”), recoupez avec :

Déploiements, mises à jour de modules et purge OPcache : gérer le “stale code” sur cPanel

Le problème opérationnel typique après activation d’OPcache, ce n’est pas “ça ne va pas plus vite”, c’est : “j’ai déployé et le site continue à exécuter l’ancien code”.

Techniquement, c’est souvent une combinaison :

validate_timestamps=0 (aucune revalidation),
absence de restart FPM,
déploiement qui ne provoque pas de rechargement (ou qui ne change pas certains timestamps comme vous l’imaginez).

Dans une infra maîtrisée, on redémarre le pool FPM au déploiement ; sur cPanel, vous ne l’aurez pas toujours. Deux stratégies réalistes en environnement cPanel :

1) Rester sur validate_timestamps=1 (voir section précédente) et accepter le coût. En e-commerce, l’impact perf de la revalidation est très souvent inférieur au bruit de la latence réseau, des IO disque et des requêtes SQL.

2) Mettre en place un endpoint de purge OPcache très verrouillé, uniquement pendant les opérations (mise à jour module, changement de thème, hotfix), puis supprimé. Exemple minimal :

<?php
// /admin-dev/opcache-reset.php (exemple) — à supprimer après usage
$allowedIp = '203.0.113.10';
if (($_SERVER['REMOTE_ADDR'] ?? '') !== $allowedIp) {
  http_response_code(403); exit('Forbidden');
}
if (!function_exists('opcache_reset')) {
  http_response_code(500); exit('No opcache_reset');
}
var_export(opcache_reset());

C’est volontairement brutal : opcache_reset() purge tout le cache, donc vos premiers hits derrière vont repasser par compilation (petit “creux” temporaire). Évitez de laisser ce fichier traîner, et évitez d’implémenter une “auth” par query string (elle finit dans les logs, parfois dans des outils tiers).

Astuce opérationnelle simple (quand vous ne pouvez pas purger) : si vous déployez par FTP et que vous suspectez un problème de prise en compte, un touch sur le fichier modifié (ou sur un fichier “entry point” souvent inclus) force un changement de timestamp — utile uniquement si validate_timestamps=1.

Si vous cherchez une approche plus propre de gestion d’erreurs côté PHP en prod (affichage/trace/log), recoupez avec : Gestion d’erreur PHP — bonnes pratiques

Dépannage : erreurs 500, cache saturé, incohérences CLI vs Web

Symptôme n°1 : HTTP 500 immédiat après modification. Causes fréquentes :

directive invalide (typo),
valeur hors borne,
directive non modifiable au niveau “user” (certaines peuvent être PHP_INI_SYSTEM selon build/hosting),
mémoire partagée impossible à allouer (rare en mutualisé “bien packagé”, mais ça arrive).

Sur cPanel, la preuve se trouve souvent dans le error_log du vhost (ou dans “Errors”/“Raw Access” selon l’UI). Ne debuggez pas à l’aveugle : remettez les directives une par une, et validez via phpinfo() côté web (pas en CLI).

Symptôme n°2 : opcache_get_status() remonte cache_full=true et le hit rate ne se stabilise pas. Vous êtes à l’étroit : augmentez opcache.memory_consumption et/ou opcache.max_accelerated_files. Le réglage « correct » dépend de votre codebase, pas d’une recette universelle. Sur PrestaShop avec beaucoup de modules, 128 Mo est fréquemment insuffisant.

Symptôme n°3 : CLI dit “OPcache enabled” mais le site ne l’utilise pas (ou inversement). C’est normal : php -v et php -i décrivent le SAPI CLI. Pour vérifier FPM, vous devez passer par phpinfo() servi par Apache/Nginx, ou par un script web qui dump PHP_SAPI + php_ini_loaded_file() :

<?php
echo PHP_SAPI, "\n";
echo php_ini_loaded_file(), "\n";

Si les ini diffèrent, vos modifications n’ont pas touché le bon contexte. C’est précisément là que MultiPHP INI Editor est préférable à des edits “au hasard” de .ini.

Symptôme n°4 (piège discret) : opcache_get_status() retourne false alors que vous voyez OPcache dans phpinfo(). Certaines configurations restreignent l’API via opcache.restrict_api (par chemin), ou bloquent l’accès aux fonctions via des politiques de sécurité. Dans ce cas, votre script de diagnostic doit être placé dans un chemin autorisé, ou vous devrez vous contenter de phpinfo().

Et si vous êtes en mutualisé avec des plafonds (mémoire, nombre de processus FPM, limites CloudLinux), vous devrez parfois arbitrer : vous ne pourrez pas atteindre une config idéale sans changer d’offre. Voir : Hébergement e-commerce — mutualisé, VPS, cloud ou SaaS comparés

OPcache dans une stratégie de performance/monitoring : mesures, seuils, corrélation

Activer OPcache est une baseline, pas une “optimisation avancée”. Le bénéfice réel se valide avec des métriques et une méthode :

TTFB (sur pages non cachées, en séparant “réseau” et “serveur” si possible),
CPU user/sys (pics corrélés aux misses/recompilations),
nombre de processus PHP-FPM et saturation (files d’attente),
statistiques OPcache (hit_rate, misses, num_cached_scripts, memory_free, cache_full).

Pour corréler correctement, il faut observer avant/après sur des scénarios identiques (mêmes caches HTTP, mêmes modules, même charge). Si vous faites déjà un audit perf structuré, OPcache rentre comme un point de contrôle serveur parmi d’autres : Audit performance PrestaShop — méthode en 6 étapes

Côté monitoring, exposer opcache_get_status() vers Prometheus/Grafana est faisable, mais sur cPanel mutualisé vous n’aurez pas toujours l’outillage pour un exporter propre. Le pattern le plus simple (quand vous avez une stack d’observabilité) consiste à :

créer un endpoint interne (protégé IP/VPN, non indexé, pas public),
extraire quelques indicateurs stables (hit rate, mémoire libre, cache_full),
déclencher des alertes sur tendance (ex. cache_full qui apparaît) plutôt que sur des seuils trop agressifs (réduction des fausses alertes).

Pour la partie dashboards/alerting, recoupez avec :

Enfin, gardez le cadre : OPcache n’empêche pas les régressions applicatives (N+1 SQL, hooks lourds, templates inefficaces) et n’améliore pas un serveur sous-dimensionné en IO. Il enlève une couche de coût « interpréteur », point. Pour le reste (cache HTTP, Redis, index MySQL, stratégie de déploiement, et limites structurelles du mutualisé), il faut traiter le système complet — et accepter que sur cPanel, certains verrous ne sautent qu’en changeant d’hébergement ou d’architecture.