Before making any change on your PrestaShop instance, it is highly recommended to perform some benchmarks.
The idea behind this is to know what your baseline performance is, so that you can make sure that your changes are increasing your shop’s performance and not the other way around.
If you’ve done no benchmark beforehand, there is no way to ensure you did not decrease your performances in the end.
Keep in mind that the surest way to tune your shop is:
benchmark
make a change
repeat
Finding your bottleneck(s)
Performance tuning can be a tricky thing, there are plenty of factors that can slow down an application.
It can come from your disks, lack of memory, network capacity, CPU: wherever you can think of.
Then, the challenge is to find your current bottleneck (could be disks access), remove it and then find the next one (could be memory).
There’s no way to enumerate all the performance issues we’ve encountered, but let’s review the more common ones and tackle them.
1) PHP
PHP tuning is very important for your application’s performance, whether you’re running PrestaShop or any other PHP software.
First, try to use PHP >=7 when possible. Hard work has been done on performance starting on this version and it will provide a nice speed boost to your shop!
If you’re using PHP-FPM (which should be the case for most “modern” installations), you have to check the pool configuration. It’s usually stored in the file /etc/php/7.x/fpm/pool.d/www.conf. Inside this file, the most important setting is the pm.max_children setting. It must be greater than the max number of concurrent users you want to simulate during the bench.
Note this PHP configuration should be used on Production environments only.
Use the following settings to optimize the performances:
[Date]
date.timezone = UTC
[Session]
session.auto_start = Off
The idea behind this is to know what your baseline performance is, so that you can make sure that your changes are increasing your shop’s performance and not the other way around.
If you’ve done no benchmark beforehand, there is no way to ensure you did not decrease your performances in the end.
Keep in mind that the surest way to tune your shop is:
benchmark
make a change
repeat
Finding your bottleneck(s)
Performance tuning can be a tricky thing, there are plenty of factors that can slow down an application.
It can come from your disks, lack of memory, network capacity, CPU: wherever you can think of.
Then, the challenge is to find your current bottleneck (could be disks access), remove it and then find the next one (could be memory).
There’s no way to enumerate all the performance issues we’ve encountered, but let’s review the more common ones and tackle them.
1) PHP
PHP tuning is very important for your application’s performance, whether you’re running PrestaShop or any other PHP software.
First, try to use PHP >=7 when possible. Hard work has been done on performance starting on this version and it will provide a nice speed boost to your shop!
If you’re using PHP-FPM (which should be the case for most “modern” installations), you have to check the pool configuration. It’s usually stored in the file /etc/php/7.x/fpm/pool.d/www.conf. Inside this file, the most important setting is the pm.max_children setting. It must be greater than the max number of concurrent users you want to simulate during the bench.
Note this PHP configuration should be used on Production environments only.
Use the following settings to optimize the performances:
[Date]
date.timezone = UTC
[Session]
session.auto_start = Off
PHP:
short_open_tag = Off
display_errors = Off
magic_quotes_gpc = off
; Increase this value if you are able to do it
memory_limit = 512M
max_execution_time = 300
max_input_time = 300
upload_max_filesize = 20M
post_max_size = 22M
; Increase this value if you work with products with a lot of combinations
max_input_vars = 20000
allow_url_fopen = on
[HEADING=2]2) PHP & File system[/HEADING]
It is well known that PHP does not manage file systems very well.
That’s why there are plenty of useful tuning options to avoid accessing the file system constantly.
[HEADING=3]realpath_cache[/HEADING]
At each file access, by default, PHP will first check that the file is still there, causing plenty of lstat system calls. Potentially thousands.
PHP provides an option to store this information in cache, so that it can avoid repeating those system calls constantly:
[PHP]
realpath_cache_size = 4096K
realpath_cache_ttl = 600
Keep in mind that this configuration is NOT compatible with other parameters, such as open_basedir and safe_mode directives.
Finally, if you’re using a NAS or any other network storage solution to store your files (in case of horizontal scaling, for example), it is [B]highly recommended[/B] to enable this setting.
[HEADING=3]opcache[/HEADING]
Because file system tuning is a never ending story, not only you can cache the files' path, but also its contents.
Good news is, OPCache will not only store your PHP files in memory, but it will store their bytecode, meaning the already compiled application, in a shared memory, available to all the application’s calls:
[opcache]
opcache.enable=1
opcache.enable_cli=0
opcache.memory_consumption=256
opcache.interned_strings_buffer=32
opcache.max_accelerated_files=16229
opcache.max_wasted_percentage=10
opcache.revalidate_freq=10
opcache.fast_shutdown=1
opcache.enable_file_override=0
opcache.max_file_size=0
If you can manage it, here are few options you could configure:
opcache.validate_timestamps=0
opcache.revalidate_path=0
Keep in mind if you deactivate validate_timestamps OPCache will never update your code unless you let it know explicitly (either through internal functions or by restarting the web server).
Also, your favorite ecommerce project made sure it’s fully compatible with OPCache.
Isn’t it nice?
[HEADING=2]3) Composer (Autoloading optimizations)[/HEADING]
The class loader used while developing the application is optimized to find new and changed classes. On production servers, PHP files should never change, unless a new application version is deployed. That’s why you can optimize Composer’s autoloader to scan the entire application once and build a “class map”, which is a big array of all the classes locations, stored in vendor/composer/autoload_classmap.php.
Execute this command to generate the class map (and make it part of your deployment process):
composer dump-autoload --optimize --no-dev --classmap-authoritative