L’une des fonctionnalités recommandées pour améliorer les performances dans PrestaShop est d’activer le « cache Smarty ».
Vous pouvez trouver cette option dans « Paramètres avancés -> Performances », mais il n’est pas toujours vrai que le mieux est de l’avoir activée.
Il existe d’innombrables modules et templates pour PrestaShop et chacun est programmé de meilleure ou moins bonne façon et à son tour intégré de meilleure ou moins bonne façon avec PrestaShop, Smarty et toute la couche de bibliothèques, APIs, hooks et autres aspects d’un CMS moderne.
Le résultat est que très souvent des « conflits » et des résultats indésirables se produisent.
Je vais utiliser comme exemple le problème trouvé avec un PS 1.6 la semaine dernière. Un rapide « top » sur le système montrait une consommation élevée de ressources de la part des processus du pool PHP-FPM. Chaque requête vers certaines pages, qui n’étaient pas toujours les mêmes bien qu’elles tendent à être des catégories, laissait un processus du pool PHP travailler pendant un temps indéfini saturant ainsi le pool de processus PHP disponibles.
La première chose à vérifier quand un processus PHP occupe trop longtemps le CPU est le slow log. Dans celui-ci un certain schéma se devinait déjà avec de nombreuses références à des fichiers CacheFs.php, smarty.config.inc.php et… un module : blocklayered-ajax.php, bien que les fichiers et fonctions ne soient pas toujours les mêmes il y avait déjà un indice intéressant.
La prochaine analyse que j’utilise habituellement, quand l’origine du problème n’est pas claire à 100%, est de voir les « appels système » que réalisent les processus en cours d’exécution. Pour cela un simple et utile strace avec le PID du processus en question m’a rapidement donné l’indice définitif. On apercevait une « boucle » apparemment infinie dans des appels de ce type :
lstat("/home/..../www/..../cache/smarty/cache//productscategory/8084/2/1/7", {st_mode=S_IFDIR|0771, st_size=3, ...}) = 0
lstat("/home/..../www/..../cache/smarty/cache//productscategory/8084/2/1", {st_mode=S_IFDIR|0771, st_size=3, ...}) = 0
lstat("/home/..../www/..../cache/smarty/cache//productscategory/8084/2", {st_mode=S_IFDIR|0771, st_size=3, ...}) = 0
lstat("/home/..../www/..../cache/smarty/cache//productscategory/8084", {st_mode=S_IFDIR|0771, st_size=3, ...}) = 0
lstat("/home/..../www/..../cache/smarty/cache//productscategory", {st_mode=S_IFDIR|0771, st_size=1929, ...}) = 0
lstat("/home/..../www/..../cache/smarty/cache", {st_mode=S_IFDIR|0771, st_size=12, ...}) = 0
lstat("/home/..../www/..../cache/smarty", {st_mode=S_IFDIR|0771, st_size=4, ...}) = 0
lstat("/home/..../www/..../cache", {st_mode=S_IFDIR|0755, st_size=11, ...}) = 0
lstat("/home/..../www/....", {st_mode=S_IFDIR|0750, st_size=114, ...}) = 0
lstat("/home/..../www", {st_mode=S_IFDIR|0750, st_size=4, ...}) = 0
lstat("/home/....", {st_mode=S_IFDIR|0750, st_size=10, ...}) = 0
lstat("/home", {st_mode=S_IFDIR|0755, st_size=7, ...}) = 0
Sans entrer dans le code ni vraiment connaître l’origine du problème (je laisse ça aux développeurs), on pouvait clairement apercevoir un problème dans la gestion du cache Smarty. Une fois désactivé dans le manager de PrestaShop, problème résolu, plus de processus PHP « bloqués » ni de pages bloquées et les performances du site avec un TTFB enviable. Sans être expert en PrestaShop, le cache Smarty est-il vraiment utile ? PrestaShop implémente un autre type de cache donc le fonctionnement conjoint de tous n’est pas très clair.
À noter que j’ai vu ce problème à plusieurs reprises et si je me souviens bien, comme cette dernière fois, sur des PrestaShop v1.6, bien qu’il soit possible que ça se produise aussi en v1.7 (cette version a subi de grands changements par rapport à la v1.6).