One of the recommended features to improve performance in PrestaShop is to enable the “Smarty cache”.
You can find this option in “Advanced Parameters -> Performance”, but it is not always true that the best option is to have it enabled.
There are countless modules and templates for PrestaShop and each one is programmed better or worse and in turn better or worse integrated with PrestaShop, Smarty and the entire layer of libraries, APIs, hooks and other aspects of a modern CMS.
The result is that very often “conflicts” and unwanted results occur.
I will use as an example the problem found with a PS 1.6 last week. A quick “top” on the system showed high resource consumption by the PHP-FPM pool processes. Each request to certain pages, which were not always the same although they tended to be categories, left a PHP pool process working for an indefinite time thus saturating the pool of available PHP processes.
The first thing to check when a PHP process occupies too much CPU time is the slow log. In it a certain pattern was already visible with numerous references to CacheFs.php files, smarty.config.inc.php and… a module: blocklayered-ajax.php, although the files and functions were not always the same there was already an interesting clue.
The next analysis I usually use, when the origin of the problem is not 100% clear, is to see the “system calls” made by the running processes. For this a simple and useful strace with the PID of the process in question quickly gave me the definitive clue. An apparently infinite “loop” was visible in calls of this 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
Without entering the code or actually knowing the origin of the problem (I leave that to the developers), a problem in Smarty cache management was clearly visible. Once disabled in the PrestaShop manager, problem solved, no more “hung” PHP processes or blocked pages and the site performance with an enviable TTFB. Without being a PrestaShop expert, is the Smarty cache really useful? PrestaShop implements another type of cache so the combined operation of all of them is not very clear.
Note that I have seen this problem on several occasions and if I remember correctly, as this last time, on PrestaShop v1.6, although it is possible that it also occurs in v1.7 (this version has undergone major changes compared to v1.6).