PrestaShop lent en back-office : quand Memcached devient le problème qu’il devait résoudre
La semaine passée, un prospect me contacte pour une intervention sur sa boutique PrestaShop.
La demande semble assez classique : mettre à jour PrestaShop pour des raisons de sécurité, mais aussi profiter de l’intervention pour essayer de comprendre pourquoi son back-office est devenu particulièrement lent.
Certaines pages mettent plusieurs secondes à se charger. Parfois beaucoup plus.
La boutique fonctionne. Les commandes passent. Le front-office est accessible.
Mais côté administration, chaque action devient pénible.
Au départ, rien ne laisse penser que le problème va venir… du système de cache.
Première étape : mettre PrestaShop à jour
Je commence donc par la mise à jour de la boutique.
Une version ancienne de PrestaShop peut évidemment poser des problèmes de sécurité, de compatibilité avec PHP ou avec certains modules. Mettre la boutique à jour était donc pertinent indépendamment du problème de performances.
J’effectue la migration, les différents contrôles habituels, puis retourne dans le back-office.
Verdict ?
Toujours aussi lent.
La mise à jour était nécessaire, mais elle n’était clairement pas la cause du problème.
Et c’est un point important : lorsqu’un PrestaShop est lent, mettre à jour le CMS, changer de version de PHP ou augmenter les ressources du serveur peut parfois améliorer les choses… mais cela ne remplace pas la recherche de la véritable cause.
La documentation PrestaShop recommande d’ailleurs de commencer une optimisation par des mesures de référence, puis de modifier un élément à la fois avant de mesurer à nouveau.
Commence alors la chasse aux secondes perdues
Je me connecte au compte OVH.
Je vérifie les ressources disponibles, les logs, les erreurs PHP et différents éléments de configuration.
Rien de suffisamment évident pour expliquer cette lenteur.
Je passe alors PrestaShop en mode debug.
Et là, première surprise.
Le back-office redevient rapide.
Plus les dizaines de secondes d’attente que j’observais précédemment.
Problème : le front-office, lui, affiche maintenant une page blanche.
Bon.
Ce n’est évidemment pas la solution, mais le changement de comportement est intéressant. Il indique surtout qu’il faut arrêter de chercher un simple problème de puissance serveur et regarder plus précisément ce qui se passe pendant l’exécution de PrestaShop.
Le profiling PrestaShop met enfin quelque chose en évidence
J’active donc le profiling de PrestaShop.
Pour ceux qui ne connaissent pas cette fonctionnalité, le profiling permet d’obtenir beaucoup plus d’informations sur l’exécution d’une page : requêtes SQL, consommation mémoire, temps d’exécution de certains traitements, hooks, etc.
C’est nettement moins joli qu’une boutique terminée.
Mais pour comprendre pourquoi une page prend 30 secondes à s’afficher, c’est beaucoup plus intéressant.
Et cette fois, j’ai une piste.
L’appel lié à config prend environ 32 secondes.
Pas 320 millisecondes.
32 secondes.
On tient clairement quelque chose.
Je commence alors à regarder plus attentivement tout ce qui touche à la configuration et au cache de cette boutique.
Et je finis par tomber sur ceci :
Memcached est activé dans PrestaShop… mais aucun serveur Memcached n’est correctement défini.
Voilà notre coupable.
Un cache qui fait attendre PrestaShop au lieu de l’accélérer
Le principe de Memcached est justement de gagner du temps.
PrestaShop peut stocker certaines informations en mémoire pour éviter de devoir les recalculer ou les récupérer systématiquement depuis une source plus lente.
Sur le papier :
PrestaShop → Memcached → réponse très rapide.
Sauf qu’ici, PrestaShop était configuré pour utiliser Memcached alors que le serveur attendu n’était plus disponible ou plus configuré.
On obtenait donc plutôt quelque chose comme :
PrestaShop → tentative de connexion à Memcached → attente → échec → poursuite du traitement.
Et cette tentative pouvait se reproduire au fil des chargements.
Le cache qui devait accélérer la boutique était devenu une source de latence.
Je désactive finalement l’option Memcached, puis je renomme temporairement le dossier de cache concerné afin de forcer PrestaShop à repartir sur un cache propre.
Je recharge le back-office.
Plus aucune lenteur.
Des pages qui demandaient auparavant plusieurs dizaines de secondes s’affichent désormais normalement.
Tout cela à cause d’une case activée depuis probablement plusieurs mois.
D’où venait cette configuration ?
Impossible d’en être absolument certain.
Mais l’explication la plus probable se trouve du côté d’une ancienne migration.
La boutique avait déjà été déplacée par le passé.
Il est donc tout à fait possible que l’ancien hébergement disposait d’un serveur Memcached correctement configuré et que cette infrastructure n’ait pas été reproduite lors de la migration.
La configuration PrestaShop, elle, est restée.
Autre possibilité : le serveur Memcached existait auparavant, puis a été supprimé ou son adresse a changé.
Dans tous les cas, le résultat est identique : PrestaShop continue d’essayer d’utiliser un service qui n’est plus correctement disponible.
Et comme la boutique ne provoquait pas nécessairement d’erreur PHP évidente, le problème a pu rester présent pendant des mois.
C’est précisément le genre de détail qui peut passer entre les mailles du filet lors d’une migration.
Mais au fait, Memcached, c’est quoi ?
Memcached est un système de cache en mémoire vive, généralement utilisé comme service séparé de PHP.
L’idée est assez simple.
Imaginez qu’une application doive régulièrement récupérer ou calculer une information relativement coûteuse.
Sans cache :
Application → traitement ou base de données → résultat.
Avec Memcached :
Application → Memcached → résultat déjà disponible en mémoire.
La RAM étant extrêmement rapide, certaines opérations peuvent ainsi être évitées.
Memcached est particulièrement intéressant dans des architectures avec plusieurs serveurs web. La documentation actuelle de PrestaShop recommande d’ailleurs, dans ce type d’architecture, d’utiliser un serveur Memcached central accessible par les différents fronts.
Mais il faut bien distinguer le serveur Memcached de l’extension PHP utilisée pour communiquer avec lui.
C’est là que les deux options suivantes présentes dans certaines versions de PrestaShop peuvent prêter à confusion.
Memcached par PHP::Memcache
La première option utilise l’extension PHP Memcache.
Cette extension permet à PHP de communiquer avec un serveur memcached.
Elle n’installe donc pas magiquement un système de cache fonctionnel.
Pour que l’ensemble fonctionne correctement, il faut notamment :
- que l’extension PHP Memcache soit disponible ;
- qu’un service Memcached fonctionne quelque part ;
- que PrestaShop connaisse l’adresse de ce serveur ;
- que le serveur soit joignable depuis l’hébergement ;
- et que le port utilisé soit correctement accessible.
L’extension Memcache existe toujours et dispose notamment de versions compatibles avec PHP 8.
C’est précisément ce dernier morceau de configuration qui posait problème dans mon cas : PrestaShop pensait pouvoir utiliser Memcached, mais aucun serveur exploitable n’était configuré.
Memcached par PHP::Memcached
Oui, les noms sont particulièrement bien choisis pour semer la confusion.
Memcache et Memcached sont deux extensions PHP différentes permettant toutes les deux de dialoguer avec le service Memcached.
L’extension PHP Memcached s’appuie sur la bibliothèque libmemcached et propose une API différente ainsi que différentes fonctionnalités supplémentaires. Elle est elle aussi toujours maintenue.
On peut donc avoir :
Serveur Memcached + extension PHP Memcache
ou
Serveur Memcached + extension PHP Memcached
Ce sont deux clients différents pour communiquer avec le même type de service de cache.
Le choix dépend principalement de la version de PrestaShop, de PHP et de la configuration du serveur.
Mais dans les deux cas, retenir ceci suffit déjà :
cocher Memcached dans PrestaShop sans disposer d’un serveur Memcached correctement configuré n’apporte aucun bénéfice.
Et peut même, comme je viens de le constater, devenir particulièrement contre-productif.
Et l’option APC ?
Sur certaines versions de PrestaShop, on retrouve également une option appelée APC.
Son fonctionnement est différent de Memcached.
Ici, il n’est pas nécessaire d’interroger un serveur Memcached distant. Le cache se situe directement dans la mémoire du serveur PHP.
C’est notamment pour cette raison que PrestaShop présente historiquement APC comme une solution adaptée aux installations avec un seul serveur, alors que Memcached devient plus intéressant lorsque plusieurs serveurs doivent partager leur cache.
Il faut cependant apporter une précision importante pour les installations modernes.
APC est une technologie historique. Aujourd’hui, on rencontre surtout APCu.
APCu reprend la partie « cache de données utilisateur » d’APC, sans son ancien système de cache d’opcodes. PHP dispose désormais d’OPcache pour cette dernière fonction. La documentation PHP décrit APCu comme un stockage clé-valeur en mémoire destiné aux applications PHP.
Si vous travaillez sur un ancien PrestaShop affichant encore explicitement « APC », il faut donc vérifier la compatibilité entre la version de PrestaShop, PHP et APCu plutôt que d’installer une extension au hasard.
À noter également que le module de rétrocompatibilité apcu-bc n’est plus pris en charge à partir de PHP 8.0.
Et XCache ?
Dernière option que l’on peut encore rencontrer sur d’anciennes interfaces PrestaShop : XCache.
Ici, on entre clairement dans la catégorie des technologies héritées.
XCache était un système de cache et d’accélération PHP que PrestaShop proposait autrefois parmi ses options. Il apparaît d’ailleurs encore dans l’ancienne documentation PrestaShop 1.7.
Mais son dépôt officiel n’a plus reçu de mise à jour depuis 2017.
Sur une infrastructure PrestaShop moderne, je ne partirais donc pas sur XCache pour une nouvelle configuration.
Si vous voyez cette option dans votre back-office, c’est surtout un indice supplémentaire que vous êtes probablement face à une ancienne version de PrestaShop ou à une configuration héritée.
Une case cochée ne signifie pas que le cache fonctionne
C’est probablement la principale conclusion que je retiens de cette intervention.
Dans un back-office, on voit :
Utiliser le cache : Oui.
On pourrait naturellement penser :
Parfait, le cache est activé, le site doit être plus rapide.
Pas forcément.
Il faut encore vérifier ce qui se trouve derrière cette option.
Un système de cache mal configuré peut être inutile. Un serveur de cache saturé peut poser problème. Un service qui n’existe plus peut provoquer des délais de connexion.
Et un réglage hérité d’une migration réalisée plusieurs années auparavant peut toujours être actif aujourd’hui.
Le cache n’est pas une formule magique.
PrestaShop lent ? Voici quelques vérifications que je ferais
Avant de chercher à changer d’hébergement ou d’ajouter davantage de CPU et de RAM, je commencerais notamment par contrôler :
- Le profiling PrestaShop, pour identifier l’endroit où le temps est réellement consommé.
- Les systèmes de cache activés dans Paramètres avancés > Performances.
- Les serveurs Memcached configurés, si Memcached est actif.
- La présence des extensions PHP correspondantes.
- L’accessibilité réelle du serveur de cache depuis le serveur web.
- Les modules, en particulier ceux appelés sur énormément de hooks.
- Les requêtes SQL particulièrement lentes.
- Les logs PHP et serveur.
- Le cache de PrestaShop, qu’il peut être pertinent de reconstruire après certains changements ou migrations.
- La différence entre les modes production et debug.
PrestaShop recommande également de désactiver les systèmes de cache comme Memcached pendant certaines procédures de mise à jour et, selon les versions, de reconstruire les répertoires var/cache/prod et var/cache/dev.
L’objectif n’est pas de tout désactiver jusqu’à ce que le site fonctionne.
C’est de mesurer, isoler, modifier, puis mesurer à nouveau.
Une petite ligne supplémentaire dans ma checklist de migration
Cette intervention n’avait finalement rien de spectaculaire.
- Pas de module corrompu.
- Pas de base de données de plusieurs centaines de gigaoctets.
- Pas de serveur à remplacer.
- Pas de bug mystérieux dans le cœur de PrestaShop.
Simplement une configuration Memcached devenue incohérente après ce qui semble être une ancienne migration.
Mais c’est justement ce type de problème qui est intéressant.
Une migration PrestaShop ne consiste pas uniquement à déplacer des fichiers et une base de données. Il faut également penser à tout l’environnement qui se trouve autour : version PHP, extensions, tâches CRON, SMTP, DNS, systèmes de cache, services externes, configuration serveur…
Une boutique peut parfaitement être migrée et continuer à fonctionner tout en conservant quelques références vers son ancienne infrastructure.
Et parfois, cette petite référence oubliée coûte 32 secondes à chaque chargement.
Depuis cette intervention, j’ai donc une ligne supplémentaire dans ma checklist :
« Vérifier les systèmes de cache et leurs serveurs après une migration. »
Ça ne prendra que quelques secondes à contrôler.
Cette fois-ci, littéralement.
FAQ
Memcached peut-il ralentir PrestaShop ?
Oui. Memcached est conçu pour améliorer les performances, mais si le serveur est inaccessible ou mal configuré, les tentatives de connexion peuvent au contraire introduire de la latence.
Faut-il obligatoirement activer le cache avancé de PrestaShop ?
Non. Il vaut mieux ne pas activer un système de cache que l’on ne maîtrise pas plutôt que de cocher une option simplement parce qu’elle semble améliorer les performances. Le choix dépend de l’infrastructure et de la version de PrestaShop.
Quelle différence entre Memcache et Memcached ?
Dans ce contexte, Memcache et Memcached désignent deux extensions PHP différentes capables de communiquer avec un serveur Memcached. Memcached repose notamment sur libmemcached.
APC et APCu sont-ils identiques ?
Non. APC est l’ancienne technologie. APCu en reprend la partie destinée au cache de données utilisateur. Sur les versions modernes de PHP, il faut vérifier ce que supporte réellement la version de PrestaShop utilisée.
XCache est-il encore recommandé ?
Pour une nouvelle infrastructure, non. Il s’agit essentiellement d’une solution historique que l’on retrouve encore dans certaines anciennes versions ou documentations PrestaShop. Son dépôt officiel n’a plus été mis à jour depuis 2017.
Sources
Documentation officielle PrestaShop sur l’optimisation et le cache : Optimiser les performances de PrestaShop
Documentation PrestaShop sur les paramètres de performances : Paramètres de performances PrestaShop
Documentation PHP : Extension PHP Memcache
Documentation PHP : Extension PHP Memcached
Documentation PHP : APCu
Dépôt historique XCache : XCache sur GitHub
