PHP : remplacer APC par OPcache et APCu

À une époque, installer APC depuis SVN sur un serveur dédié pouvait avoir du sens. APC, pour Alternative PHP Cache, servait alors à accélérer PHP en mettant en cache le code compilé, mais aussi à stocker des données applicatives en mémoire.

Ce temps est terminé. Aujourd’hui, il ne faut plus installer APC. Et encore moins depuis SVN, à la main, sur un serveur de production. Là, on n’optimise plus PHP : on invoque l’archéologie système.

La pile moderne est simple : utilisez OPcache pour le cache d’opcode PHP, puis ajoutez APCu uniquement si votre application a besoin d’un cache utilisateur local.

BigScoots: Premium WordPress and WooCommerce hosting

APC, OPcache, APCu : qui fait quoi ?

Le point important est de ne pas confondre les trois noms.

Nom	Rôle	Statut actuel
APC	Ancien cache d’opcode + cache utilisateur	Obsolète, à ne plus installer
OPcache	Cache d’opcode PHP	Solution standard intégrée à PHP
APCu	Cache utilisateur en mémoire locale	Remplacement moderne de la partie user cache d’APC

OPcache améliore les performances en stockant en mémoire partagée le bytecode précompilé des scripts PHP. PHP n’a donc pas besoin de relire et recompiler les mêmes fichiers à chaque requête.

APCu, lui, ne remplace pas OPcache. Il sert à stocker des valeurs applicatives en mémoire : résultats coûteux, fragments de données, petits états locaux, caches temporaires. Il ne met pas le code PHP en cache.

En clair : OPcache pour le code, APCu pour les données.

Pourquoi APC n’est plus la bonne solution

APC appartenait au monde PHP 5 ancien. Il combinait deux fonctions : cache d’opcode et cache utilisateur. Depuis PHP 5.5, OPcache est devenu la solution intégrée pour le cache d’opcode. APC a donc perdu son rôle principal.

Le problème d’APC aujourd’hui :

il n’est plus adapté aux versions modernes de PHP ;
il entre en concurrence conceptuelle avec OPcache ;
il pousse à compiler des extensions à la main ;
il complique les mises à jour serveur ;
il ajoute de la dette technique inutile.

Si un vieux projet réclame encore APC, vérifiez d’abord s’il accepte APCu. Beaucoup de vieux codes qui appelaient apc_store(), apc_fetch() ou apc_delete() peuvent migrer vers APCu avec une adaptation légère, parfois via une couche de compatibilité.

Kinsta: Premium Managed WordPress hosting

Installer OPcache sur Ubuntu ou Debian

Sur les installations PHP modernes, OPcache est souvent déjà installé ou disponible via le paquet PHP correspondant.

Pour vérifier si OPcache est chargé :

php -m | grep -i opcache

Vous pouvez aussi vérifier depuis PHP :

php -i | grep -i "opcache.enable"Code language: JavaScript (javascript)

Sur Ubuntu ou Debian, installez le paquet adapté à votre version de PHP. Exemple avec PHP 8.3 :

sudo apt update
sudo apt install php8.3-opcacheCode language: CSS (css)

Si votre distribution utilise un paquet générique :

sudo apt install php-opcache

Redémarrez ensuite PHP-FPM ou Apache selon votre pile.

Avec PHP-FPM :

sudo systemctl reload php8.3-fpmCode language: CSS (css)

Avec Apache mod_php :

sudo systemctl reload apache2

Avec Nginx, c’est bien PHP-FPM qu’il faut recharger, pas Nginx, sauf si vous avez aussi modifié la configuration Nginx.

Configurer OPcache proprement

Le fichier de configuration dépend de votre distribution et de votre version de PHP. Sur Ubuntu/Debian avec PHP-FPM, il ressemble souvent à ceci :

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

Ou :

/etc/php/8.3/mods-available/opcache.ini

Configuration de base raisonnable pour un site PHP classique :

opcache.enable=1
opcache.enable_cli=0
opcache.memory_consumption=256
opcache.interned_strings_buffer=32
opcache.max_accelerated_files=100000
opcache.validate_timestamps=1
opcache.revalidate_freq=2
opcache.save_comments=1
opcache.jit=0

Pour WordPress, gardez opcache.save_comments=1. Certains plugins, frameworks et outils d’introspection peuvent dépendre des commentaires PHP, notamment pour les annotations ou la réflexion.

Le JIT n’est généralement pas utile pour WordPress, WooCommerce ou la plupart des applications web PHP classiques. Il peut même ajouter de la complexité sans gain visible. OPcache sans JIT apporte déjà le gros du bénéfice utile.

Vérifier l’état d’OPcache

En ligne de commande, vous pouvez obtenir la configuration OPcache :

php --ri "Zend OPcache"Code language: JavaScript (javascript)

Pour vérifier les fichiers de configuration chargés :

php --ini

Attention : la configuration CLI et la configuration FPM peuvent différer. Un php -i en console ne prouve pas toujours que le pool FPM utilisé par votre site charge exactement les mêmes réglages.

Pour vérifier côté web, utilisez une page phpinfo() temporaire, protégée ou limitée à votre IP, puis supprimez-la immédiatement après test.

<?php

phpinfo();Code language: HTML, XML (xml)

Ne laissez jamais un fichier phpinfo() accessible publiquement. Il expose trop d’informations sur votre serveur.

Installer APCu seulement si nécessaire

APCu est utile si votre application utilise explicitement un cache utilisateur local. Ce n’est pas obligatoire pour tous les sites PHP.

Pour installer APCu avec PHP 8.3 sur Ubuntu ou Debian :

sudo apt update
sudo apt install php8.3-apcuCode language: CSS (css)

Ou avec le paquet générique si votre distribution le propose :

sudo apt install php-apcu

Rechargez PHP-FPM :

sudo systemctl reload php8.3-fpmCode language: CSS (css)

Vérifiez que l’extension est chargée :

php -m | grep -i apcu

Ou :

php --ri apcu

Codeable: trouvez les meilleurs développeurs WordPress

Configuration APCu de base

Un fichier de configuration APCu peut ressembler à ceci :

apc.enabled=1
apc.shm_size=128M
apc.ttl=7200
apc.gc_ttl=3600
apc.entries_hint=4096
apc.enable_cli=0

Le réglage apc.enable_cli=0 est généralement préférable. Activez APCu en CLI seulement si vous avez un besoin précis, comme un script long qui utilise explicitement APCu.

Ne dimensionnez pas APCu au hasard. Si l’application n’utilise presque pas le cache utilisateur, 512 Mo d’APCu ne rendront pas votre serveur héroïque. Ils rendront surtout votre configuration plus généreuse que nécessaire.

Tester APCu avec un mini-script

Vous pouvez vérifier qu’APCu fonctionne avec un petit test PHP. À lancer en environnement de test, pas à laisser exposé publiquement.

<?php

declare(strict_types=1);

$key = 'skyminds_test_key';

apcu_store( $key, 'APCu fonctionne', 60 );

$value = apcu_fetch( $key );

var_dump( $value );Code language: HTML, XML (xml)

Si APCu fonctionne, vous devriez voir :

string(15) "APCu fonctionne"Code language: JavaScript (javascript)

Supprimez ce fichier de test après usage. Un script de diagnostic oublié dans un webroot finit rarement en poésie.

Le plus lu : Mise à jour du serveur : passage de Debian Lenny à Debian Squeeze

WordPress : OPcache oui, APCu pas toujours

Pour WordPress, OPcache doit presque toujours être activé sur un serveur PHP-FPM moderne. C’est un gain simple, stable et largement attendu.

APCu, en revanche, ne devient utile que si WordPress ou un plugin l’utilise comme cache d’objet. Dans l’écosystème WordPress, Redis ou Memcached sont souvent plus adaptés pour un cache d’objet persistant, surtout sur une architecture multi-processus, multi-serveur ou hébergée.

APCu est local au processus et au serveur. Il peut être utile pour un site simple sur un seul serveur, mais il n’est pas un remplaçant universel de Redis.

Pour un site WooCommerce, testez toujours soigneusement le cache d’objet. Un mauvais cache peut faire plus de dégâts qu’un site non caché. Le panier, les sessions, les prix dynamiques et les fragments doivent rester cohérents.

Migration d’un vieux code APC vers APCu

Si une vieille application utilise encore les fonctions APC, vous verrez peut-être du code comme ceci :

<?php
apc_store( 'key', 'value', 300 );
$value = apc_fetch( 'key' );
apc_delete( 'key' );Code language: HTML, XML (xml)

Avec APCu, l’équivalent moderne est :

<?php
apcu_store( 'key', 'value', 300 );
$value = apcu_fetch( 'key' );
apcu_delete( 'key' );Code language: HTML, XML (xml)

La migration peut sembler triviale, mais vérifiez toujours le contexte : gestion des erreurs, valeurs retournées, TTL, préfixes de clés, invalidation et concurrence.

Pour trouver les anciens appels APC :

grep -RIn --include="*.php" 'apc_' .Code language: PHP (php)

Corrigez ensuite dans une branche Git ou sur un environnement de staging. Pas directement sur la production, sauf si vous aimez les sueurs froides comme outil de monitoring.

Ne compilez pas une extension PHP à la main sans bonne raison

L’ancien article passait par SVN, phpize, configure et make. Aujourd’hui, ce n’est plus la bonne méthode par défaut.

Compiler une extension PHP à la main implique :

de gérer les dépendances de build ;
de recompiler après certaines mises à jour PHP ;
de surveiller les ABI et versions exactes ;
de documenter l’installation pour le prochain admin ;
de maintenir un écart avec les paquets de la distribution.

Sur un serveur de production, préférez les paquets maintenus. C’est moins héroïque, mais beaucoup plus durable. Et l’héroïsme en production finit souvent dans les logs d’erreur.

OPcache avec déploiement : attention aux timestamps

Le réglage opcache.validate_timestamps mérite une attention particulière.

Avec :

opcache.validate_timestamps=1
opcache.revalidate_freq=2

PHP vérifie régulièrement si les fichiers ont changé. C’est pratique sur un site WordPress ou un serveur où les mises à jour peuvent modifier des fichiers.

Le plus lu : Linux : installation d'une carte WiFi b/g/n Broadcom 43222

Avec :

opcache.validate_timestamps=0

PHP ne vérifie plus les changements automatiquement. Cela peut améliorer légèrement les performances sur des déploiements contrôlés, mais vous devez alors vider OPcache à chaque déploiement ou recharger PHP-FPM.

Pour WordPress classique, gardez généralement validate_timestamps=1. Les mises à jour de plugins et thèmes doivent être prises en compte sans procédure spéciale.

Réinitialiser OPcache après un déploiement

Si vous désactivez la validation des timestamps, ou si vous observez un comportement étrange après un déploiement, vous pouvez recharger PHP-FPM :

sudo systemctl reload php8.3-fpmCode language: CSS (css)

Vous pouvez aussi appeler opcache_reset() depuis un outil interne sécurisé, mais ne laissez jamais un endpoint public faire cela. Réinitialiser OPcache publiquement, c’est offrir un bouton rouge à Internet. Internet adore les boutons rouges.

Surveillance et dépannage

Après activation, surveillez les logs PHP-FPM :

journalctl -u php8.3-fpm -n 100 --no-pagerCode language: CSS (css)

Vérifiez aussi les erreurs Nginx ou Apache selon votre pile :

sudo tail -n 100 /var/log/nginx/error.logCode language: JavaScript (javascript)

Ou :

sudo tail -n 100 /var/log/apache2/error.logCode language: JavaScript (javascript)

Si PHP-FPM refuse de redémarrer après modification d’un fichier .ini, vérifiez la syntaxe et les directives inconnues. Une directive mal orthographiée suffit parfois à casser le démarrage.

Checklist moderne pour remplacer APC

Ne plus installer APC.
Ne plus installer d’extension PHP depuis SVN en production.
Activer OPcache pour le cache d’opcode PHP.
Ajouter APCu seulement si l’application utilise un cache utilisateur local.
Préférer les paquets maintenus de la distribution ou du dépôt PHP utilisé.
Tester les réglages avec PHP-FPM, pas seulement en CLI.
Sur WordPress, garder opcache.save_comments=1.
Sur WooCommerce, tester tout cache d’objet avec prudence.
Documenter les réglages dans le runbook serveur.

À retenir

APC n’est plus l’outil à installer pour accélérer PHP. L’ancienne méthode via SVN doit rester dans les archives, pas dans un runbook serveur actuel.

Utilisez OPcache pour accélérer l’exécution PHP. Ajoutez APCu seulement si votre code a besoin d’un cache utilisateur local. Pour WordPress et WooCommerce, évaluez aussi Redis ou Memcached si vous cherchez un cache d’objet persistant.

La règle est simple : OPcache d’abord, APCu si besoin, compilation manuelle seulement en dernier recours. Le serveur ira plus vite, et le prochain admin évitera de vous maudire à voix basse.