5.2Performance : cache, OPcache, Redis
L'essentiel en 30 secondes
- OPcache : le bytecode compilé est mis en cache — compilation une seule fois au lieu de chaque requête, gain majeur quasi gratuit.
- Cache applicatif : stocker les résultats coûteux (Redis) pour ne pas les refaire — souvent le levier le plus impactant.
- Mesurer d'abord : profiler pour trouver le vrai goulot (souvent la base) — jamais d'optimisation prématurée.
Mini-cas filé — Riad accélère sa boutique à Constantine
La boutique restructurée de Riad à Constantine rame aux heures de pointe : la page d'accueil met du temps à répondre. Plutôt que de tout réécrire, il mesure : l'OPcache n'est pas activé en production, et les mêmes requêtes catalogue sollicitent la base sans cesse. Il active l'OPcache et met le catalogue en cache. Suite du cas 5.1 — Riad optimise ce qu'il a mesuré, pas au hasard.
Suite du cas 5.1 — Riad applique la règle d'or : mesurer d'abord, optimiser ensuite.
1. OPcache : le gain quasi gratuit
PHP est interprété : à chaque requête, le serveur compile le code (en « bytecode ») avant de l'exécuter. Refaire cette compilation à chaque requête, alors que le code ne change pas, est du gaspillage. L'OPcache est une extension (généralement disponible) qui met en cache le bytecode compilé : on compile une fois, puis on réutilise — un gain de performance majeur et quasi gratuit. Riad vérifie qu'il est activé et bien configuré en production (en développement, on le désactive parfois pour voir les changements aussitôt). Les versions modernes de PHP apportent en outre d'importants gains intrinsèques.
Réflexe : une application PHP en production sans OPcache est nettement plus lente sans raison — c'est l'optimisation de base, avant toute autre.
2. Le cache applicatif et Redis
Le levier le plus impactant sur les applications réelles est la mise en cache : stocker des résultats coûteux et peu changeants (requêtes fréquentes, calculs lourds, pages ou fragments, données d'API externes) pour ne pas les refaire à chaque requête. Pour un cache rapide et partagé, on utilise souvent Redis (ou Memcached) — un stockage en mémoire, donc très rapide, qui sert aussi pour les sessions ou les files d'attente. Les frameworks (Laravel, Symfony) intègrent des systèmes de cache faciles à utiliser, avec plusieurs pilotes. Riad met le catalogue en cache avec une durée de vie courte : les requêtes répétées ne touchent plus la base.
Règle de choix : on cache ce qui est coûteux à produire et supporte d'être légèrement différé — avec une stratégie de rafraîchissement claire.
3. Base, profilage et bonne démarche
La base de données est souvent le vrai goulot : requêtes lentes ou non indexées, et le fameux problème N+1 (fréquent avec les ORM : une requête par élément d'une liste au lieu d'une seule — corrigé par le chargement groupé des relations, « eager loading »). Indexer les colonnes recherchées et optimiser les requêtes a souvent le plus grand impact. Et la méthode qui surplombe tout : le profilage — mesurer avant d'optimiser pour identifier les vrais goulots plutôt qu'optimiser à l'aveugle. Riad profile avant de toucher au code : la lenteur venait de la base, pas de ses boucles.
Principe transversal : ne pas optimiser prématurément. Code correct et clair d'abord, mesure quand un problème survient, optimisation ciblée ensuite. Optimiser trop tôt fait perdre du temps et complexifie inutilement.
🔎 Exemple concret — Riad met le catalogue en cache
Vérifier l'OPcache, puis cacher un résultat coûteux.
query('SELECT id, nom, prix FROM produits')->fetchAll(PDO::FETCH_ASSOC);
file_put_contents($fichier, json_encode($lignes));
return $lignes;
}Lecture : on vérifie le gain gratuit (OPcache), puis on évite de refaire le coûteux (cache avec durée de vie).
Leçon : en production, ce cache vivrait dans Redis — partagé entre tous les processus.
Vocabulaire de la section
- OPcache
- Extension qui met en cache le bytecode PHP compilé, compilé une seule fois.
Exemple simple : Riad l'active en production : fini la recompilation à chaque requête.
Ce que ce n'est pas : un cache de pages HTML.
Réflexe : l'OPcache est-il actif sur ma production ?
- Mise en cache
- Stocker les résultats coûteux pour ne pas les recalculer à chaque fois.
Exemple simple : Le catalogue de Riad servi depuis le cache, plus depuis la base.
Ce que ce n'est pas : ajouter des serveurs avant de cacher.
Réflexe : quelles requêtes reviennent sans cesse à l'identique ?
- Redis
- Stockage en mémoire rapide, souvent utilisé comme cache partagé.
Exemple simple : Riad y place le catalogue avec une courte durée de vie.
Ce que ce n'est pas : la base de données principale elle-même.
Réflexe : ce résultat supporte-t-il d'être légèrement différé ?
- Problème N+1
- Une requête par élément d'une liste au lieu d'une seule requête groupée.
Exemple simple : Riad charge les avis de 50 produits en une fois, pas en 50 requêtes.
Ce que ce n'est pas : un manque de mémoire sur le serveur.
Réflexe : combien de requêtes partent pour afficher cette liste ?
- Profilage
- Mesurer pour identifier les vrais goulots avant d'optimiser.
Exemple simple : Riad découvre que la lenteur vient d'une requête non indexée.
Ce que ce n'est pas : optimiser ses boucles à l'intuition.
Réflexe : ai-je mesuré avant de toucher au code ?
En pratique — Optimiser une application PHP
- Vérifiez que l'OPcache est activé et bien configuré (surtout en production) — un gain de performance majeur quasi gratuit (bytecode compilé mis en cache).
- Mettez en cache un résultat coûteux (requête fréquente) — en mémoire ou avec Redis — et mesurez le gain ; utilisez le système de cache d'un framework.
- Optimisez la base : indexez les colonnes recherchées, repérez et corrigez le problème N+1 (chargement groupé des relations) — souvent le plus grand impact.
- PROFILEZ pour identifier les vrais goulots AVANT d'optimiser (mesurer avant d'optimiser) ; n'optimisez pas prématurément (code correct d'abord).
Script prêt à dire — justifier une optimisation
« À Constantine, notre boutique ralentit aux heures de pointe. J'ai mesuré : l'OPcache n'est pas actif en production et les requêtes catalogue saturent la base. Je propose deux gestes ciblés : activer l'OPcache et mettre le catalogue en cache avec une courte durée de vie. On re-mesure après, et on ne touche à l'infrastructure que si la mesure le justifie. »
À dire au responsable pour faire valider une optimisation mesurée plutôt qu'une réécriture à l'aveugle.
Modèle copier-coller — fiche diagnostic perf
PERF — DIAGNOSTIC
SYMPTOME : _______________ (quand ? ___)
OPCACHE : actif en production ? ___
MESURE : temps de réponse ___ · requête la plus lente ___
GOULOT SUSPECTE : cache absent / base (index, N+1) / code : ___
ACTION CIBLEE : OPcache / cache Redis / index / eager loading : ___
RE-MESURE : avant ___ → après ___ · GAIN : ___Solo / petit budget
Riad seul : OPcache + cache fichier sur les pages coûteuses suffit — Redis viendra quand le trafic le justifie.
TPE / équipe réduite
Indexer les requêtes lentes d'abord : souvent le gain le plus rapide, sans nouvelle infrastructure.
PME à Constantine
Riad planifie les mesures aux heures de pointe à Constantine, avec un protocole de re-mesure après chaque changement.
Équipe qui démarre
Binôme : l'un profile pendant que l'autre prépare le cache ; revue commune des mesures avant toute optimisation.
✓ Bonnes pratiques
- Vérifier l'OPcache en production avant toute autre optimisation (le gain gratuit).
- Mettre en cache les résultats coûteux ; indexer et corriger le N+1.
- Mesurer (profiler) avant d'optimiser, et cibler les vrais goulots.
✗ Pièges fréquents
- Optimiser ses boucles à l'intuition sans mesurer (le goulot est ailleurs).
- Oublier l'OPcache en production (lenteur sans raison).
- Mettre en cache sans durée de vie ni stratégie de rafraîchissement (données périmées).
Points clés à retenir
- OPCACHE : met en cache le BYTECODE PHP compilé (compilation une seule fois au lieu de chaque requête) — gain MAJEUR quasi gratuit. À activer/configurer, surtout en production.
- MISE EN CACHE (souvent le plus impactant) : stocker les résultats COÛTEUX (requêtes fréquentes, calculs, pages) pour ne pas les refaire ; REDIS (stockage en mémoire rapide). Les frameworks intègrent le cache.
- OPTIMISATION de la BASE (souvent le vrai goulot) : indexer, optimiser les requêtes, corriger le N+1 (chargement groupé). PROFILER (mesurer) AVANT d'optimiser (règle d'or).
- NE PAS optimiser PRÉMATURÉMENT : code correct et clair d'abord, MESURER quand un problème survient, puis optimisation CIBLÉE. Optimiser trop tôt = temps perdu + complexité inutile.
Défi 48h — appliquez demain
Remplissez la fiche diagnostic pour 1 lenteur réelle de votre app : OPcache vérifié, mesure, goulot suspecté — sans encore toucher au code.
- Je peux expliquer OPcache vs cache applicatif en une phrase.
- Ma fiche diagnostic (mesure avant optimisation) est remplie.
- Je sais pourquoi la base est le premier suspect.
Questions fréquentes
Qu'est-ce que l'OPcache et le cache, et comment améliorer les performances d'une application PHP ?
Deux mécanismes différents et complémentaires. L'OPcache résout un gaspillage propre à PHP : recompiler le code à chaque requête. Il met en cache le bytecode compilé — on compile une fois, on réutilise — gain majeur quasi gratuit, à activer surtout en production. Le cache applicatif résout un autre gaspillage : refaire des opérations coûteuses (requêtes fréquentes, calculs, pages) alors que le résultat change peu. On stocke le résultat (souvent dans Redis, en mémoire, très rapide) avec une durée de vie. À cela s'ajoutent l'optimisation de la base (index, correction du N+1 — souvent le vrai goulot) et le profilage : mesurer pour optimiser là où ça compte, jamais à l'aveugle.
Comment savoir quand et quoi optimiser sans tomber dans l'optimisation prématurée ?
Règle d'or : n'optimisez pas avant un problème réel et mesuré. L'optimisation prématurée fait perdre du temps, complexifie le code et rate le vrai goulot (l'intuition trompe). La démarche : code correct et clair d'abord, mesurer (profilage, temps de requêtes) quand un problème survient, optimiser ciblé là où ça compte (OPcache, cache, base), re-mesurer pour confirmer le gain. La plupart du code n'a pas besoin d'être optimisé : une petite partie concentre l'essentiel du coût — la mesure la désigne.
Quel est le premier réflexe performance sur une app PHP en production ?