Performance and Caching

Numbers help only when they come with their method. The test shop ran in two containers of the official image against the same MySQL database: the shared development container (PS_DEV_MODE=1, port 8080) and a production-mode copy (PS_DEV_MODE=0, on a copy of the shop’s volume so that changing app/config/parameters.php or the PHP configuration could not affect anybody else). The home page was requested with curl three times to warm every cache, then 20 to 25 times in a row; the figures are the median of the total time. Each variation was measured in three rounds that were interleaved (baseline, variation, next variation, …​) so that load on the machine, which was shared with other work, hit all of them alike. The chart shows the median of the three round medians and, as a thin line, the lowest and the highest round median.

Source: Docker Hub: prestashop/prestashop

What the measurements say, with the caution that they come from one laptop, one container and one page:

The conclusion to carry away: switch the production mode on first, then make sure OPcache works, then use the SQL cache if the catalogue is large, and treat everything else as a smaller gain that is worth measuring on your own pages.

On a classic host, set the constant in config/defines_custom.inc.php (the back-office switch reads and writes that file first when it is readable, and falls back to config/defines.inc.php):

Source: PrestaShop devdocs: Configuring PrestaShop

The same switches exist in Advanced Parameters > Performance > Debug mode: "Debug mode", an optional debug cookie name and value (so that only a browser that carries the cookie sees the debug mode, which is useful for diagnosing a production issue without exposing errors to every visitor), and "Debug profiler". "Disable all overrides" is in the same panel and turns off every class and controller override at once, which tells you in seconds whether an override is the cause of a problem. The page writes the constant into the defines file, which requires that file to be writable by the web user.

With the Docker image, the variable PS_DEV_MODE decides. The image default is 0; the table in the official Docker page that says 1 is wrong. The value is read with PHP’s (bool) getenv(...), so PS_DEV_MODE=false (a non-empty string) means true: write 0 or leave the variable out. The console command prestashop:debug does not understand this setup (it reported ON in a container started with PS_DEV_MODE=0 and, when asked to switch off, replaced the environment-driven line with a fixed constant), so on Docker change the variable of the container, see the CLI commands page.

Source: PrestaShop devdocs: Docker

The debug profiler (Debug profiler switch, or _PS_DEBUG_PROFILING_) appends a panel to every page with the load time, the query time, the number of queries, the peak memory, the number of included files, the list of queries with their durations, the tables that are queried most often, the duplicated queries and the ObjectModel instances. It is the tool for finding a module that costs hundreds of queries. On the test shop, a cold first request after clearing the cache showed 722 queries, 2061 ms, 2003 included files and 52.8 MB, and warm requests 325 queries, 58 ms and 1110 files: always measure warm. The panel adds about 3 MB to the page, so never leave it on for visitors; to profile one request on a production host, use a debug cookie and a short window.

The page on configuring PrestaShop says the Smarty cache "should always be disabled" and shows $smarty->caching = false in config/smarty.config.inc.php; the optimisation page says to enable the Smarty cache. Both are true, because they talk about different things. The configuration file sets Smarty’s own caching to CACHING_OFF for every template, and that is not changed by any setting, so whole templates are not cached. What the Cache switch (PS_SMARTY_CACHE) controls is the helper Tools::enableCache(), which a module calls around the part of its code that it wants cached: if the switch is off, the helper does nothing, and the module renders its block again on each request; if it is on, the helper turns Smarty’s caching on for that template with a one-year lifetime and a cache id. On the test shop the modules that cache this way were ps_banner, ps_customeraccountlinks, ps_customtext, ps_imageslider, ps_linklist and ps_socialfollow: each has a directory under var/cache/<env>/smarty/cache.

Modules are free to keep their own caches too. The main menu of the home page is not cached in Smarty: ps_mainmenu stores the menu as a JSON file, var/cache/<env>/ps_mainmenu/<shop id>/MOD_BLOCKTOPMENU_MENU_JSON_<...>.json. That gave a clear demonstration in the test: a category name changed directly in the database was shown at once on the category page, but the menu of the home page kept the old name until the cache was cleared.

Source: PrestaShop devdocs: Configuring PrestaShop

bin/console cache:clear --env=prod removed the whole var/cache/prod directory, Smarty compile and cache directories and the module caches included; after it, the first request recompiled 48 templates and refilled six Smarty cache directories.

Two lessons for the people who manage a shop. Changes made through the back office clear the right caches (the module listens to the hooks of the data it shows), but changes made by SQL scripts, imports that bypass ObjectModel, or another application are invisible until the Smarty cache is cleared: add a cache clear to every such job. And a module that caches output without a good cache id (per language, per currency, per customer group, per shop) can show the wrong content to the wrong visitor; the official page notes the opposite risk, over-caching, which scatters hundreds of cache files over the disk.

The Smarty directories live in var/cache/<env>/smarty/{compile,cache}. On the test shop the compile directory held 80 files (1.4 MB) and the cache directory 6 files. PrestaShop 1.6 had a "Cache storage" setting (file system or MySQL) that older books and posts still describe; it does not exist in 9.2.0 (the form has the four fields above only), so the advice to choose "file system" is moot.

APCu is not in the official image. The steps below were run on the production-mode copy and the effect is the "SQL cache" row of the measurements (325 statements per home page became 28).

Source: PHP manual: APCu installation

A syntax detail: app/config/parameters.php is generated, not meant for hand edits, but the Performance page writes exactly these keys, so a scripted edit equals clicking. If the extension is missing when the cache is enabled the shop throws APC cache has been enabled, but the APC or APCu extension is not available on every request, so add the extension first.

Memcached works the same way with the other two systems and a server list. It was not run (no Memcached in the test environment). Use it when more than one front-end server must share the cache; place the Memcached server on the private network, never on localhost of a farm, and never expose its port to the internet.

OPcache stores compiled PHP files in shared memory. Without it every request compiles about 1100 files for a front-office page (2000 on the first request after a cache clear): 202 ms instead of 76 ms in the test. It is enabled in the image. The values that the image uses, those that the official page recommends, and what the test showed:

Source: PHP manual: OPcache

The status function describes the OPcache of the process that answers, so it has to be called through the web server; run on the command line it describes a different cache (or none). opcache.validate_timestamps=0 and every cache of var/cache mean that a new version of a module is invisible until the deployment reloads PHP and clears the caches: both belong in the deployment script.

For FPM, set pm.max_children high enough for the peak number of concurrent requests that you expect, and small enough that the workers fit in memory (measure it: the peak of the home page was 10.7 MB per request, the back office needs far more), pm = dynamic or ondemand according to traffic, and pm.max_requests to recycle workers. The official page gives the Apache event MPM example ServerLimit 16, MaxRequestWorkers 400. The image of the test shop uses mod_php with prefork, where each Apache child embeds PHP; do not copy FPM numbers into it.

The image has deflate, headers and rewrite loaded and no expires. The .htaccess that PrestaShop writes contains an <IfModule mod_expires.c> block with expiry times (images one month, CSS and JavaScript one week, fonts and SVG one year) and an <IfModule mod_deflate.c> block. Because <IfModule> ignores a block when the module is absent, the "Apache optimization" switch silently did nothing in the Docker image: the CSS file was answered with Last-Modified and no Cache-Control or Expires, so a browser could only revalidate it. Enabling the module fixed it:

Source: PrestaShop devdocs: Optimize your Apache httpd configuration

Compression was on already: the home page was 133 KB identity and 15 KB with gzip, the combined CSS 440 KB and 84 KB. Other Apache settings: the official page offers Header set Cache-Control "max-age=2592000, public" for images, CSS and fonts as a mod_headers alternative to mod_expires, and FileETag none is already in the generated block. Standard Apache practice, not part of the PrestaShop page and not run here, adds HTTP/2 (Protocols h2 http/1.1, which needs the event or worker MPM with PHP-FPM, not prefork with mod_php), KeepAlive On, and moving the .htaccess rules into the virtual host with AllowOverride None, which saves a file look-up in every directory of every request. The HTML of the shop is sent with Cache-Control: no-store, no-cache, must-revalidate and an old Expires, which is right: do not try to cache the dynamic pages in a CDN without a very careful design (cart and customer cookies make a page personal).

Nginx has no .htaccess, so the Apache optimization switch is irrelevant and the equivalents belong in the server block. The official page gives compression and expiry rules, adapted here (the type list is shortened and webp and avif were added to the expiry pattern); they were not run:

Source: PrestaShop devdocs: Optimize your nginx configuration

The official text warns about compression over TLS (BREACH). Mitigate it by not compressing responses that reflect a secret (the shop’s HTML includes CSRF tokens in forms), or accept it with the usual protections. Buffer the access log (access_log ... buffer=32k flush=5s) or switch it off for static files. With Nginx in front of PHP-FPM, the deny rules that .htaccess provides (see the Security page) must be reproduced in location blocks.

The official page "Taking care of your PrestaShop" lists tables that grow with traffic: the logs (ps_log), the visit tracking (ps_connections, ps_connections_source, ps_connections_page, ps_guest, ps_page_viewed), the 404 page log (ps_pagenotfound), the search statistics (ps_statssearch), old abandoned carts (ps_cart and ps_cart_product) and, in some shops, ps_mail and the search index. On the test shop ps_connections, ps_connections_source and ps_guest already had about 700 rows after a day of tests, one row per visitor session, which at a few thousand visitors a day means millions of rows in a year. A purge such as this one (wrapped in a transaction and rolled back on the test shop to check the syntax; it removed nothing there because every row was recent) belongs to a scheduled job that runs off peak:

Source: PrestaShop devdocs: Taking care of your PrestaShop

Keep a backup first, delete in batches (LIMIT 10000 in a loop) on large tables so as not to hold locks for minutes, and check that no module’s reports depend on the rows you purge: the statistics modules read ps_connections and ps_guest, so their old figures will go with them. For ps_guest remove only guests without a customer account. The statistics modules themselves are a performance choice: each page view writes rows, and a shop that uses Google Analytics or another external tool can disable the internal ones.