A lot of things have been improved on PrestaShop 220.127.116.11:
We have done a lot of work to improve the overall performances of PrestaShop, and reached in some cases a whooping 10x improvement.
Let’s now dig into the optimizations we have put in place, and do some benchmarks.
Note: This article was first published by Jocelyn on his blog at Softizy. Read the original here.
Which parts of PrestaShop are faster?
Faster single-threaded performances
Thanks to our internal tools (to be publicly released soon!), we quickly identified the bottlenecks of PrestaShop which were directly impacting the generation time of some pages, and hence the SEO and user satisfaction.
At the PHP level, with the cache deactivated and after launching a crawl on a real shop, we collected all the data we needed in a few minutes:
Same at the SQL level:
Thanks to these findings, we have rewritten a large amount of SQL queries to improve their efficiency, and we improved the PHP core to remove the detected bottlenecks.
Faster multi-threaded performances
Beside the huge work on the query performances, we have worked a lot on the SQL queries to make sure the MySQL query cache is used efficiently. We also fixed a few nasty issues in the PrestaShop cache. Actually, most of the time the use of the PrestaShop cache was decreasing the performance. This is no longer the case!
Specific optimizations for multi-front / cloud environment
PrestaShop is using Smarty to handle the templates. If you are using several front servers, the out of the box Smarty implementation forces you to centralize its cache on a shared filesystem (NFS).
To remove this limitation, we added a custom Smarty module which makes it work perfectly with a local Smarty cache (no more NFS needed!). Moreover, our implementation sped up a lot the cases where the cache had to be invalidated: instead of flushing all the files at once, each template is flushed asynchronously.
This quickened a lot all the back office operations!
Better back office performances
We removed the most frustrating bottleneck in the PrestaShop back office:
- Faster imports: We worked hard to improve the import speed. The more you import products, the more you’ll see the speed up!
- Better search indexing: We improved both the memory usage and the search indexing speed.
- No more issue with huge cart rules or categories: Cart rules and categories are now loaded asynchronously.
To do this benchmark, we chose to use a dedicated Mini HG server from OVH, which offers high performances for a fairly decent price:
- CPU: Intel(R) Xeon(R) CPU E5-2650 v2 @ 2.60GHz (8 cores, 16 threads)
- Memory: 64 GB
- Disk: 2x SSD 600 GB
- RAID Controller: LSI MegaRAID SAS 9271-4i CacheVault 1G FastPath
We used a Debian Jessie, with the standard packages, and a properly optimized configuration:
- Apache 2.4.10, with mpm_event and the following configuration:
ServerLimit 16 MaxClients 400 StartServers 3 ThreadLimit 64 ThreadsPerChild 25 MaxRequestWorkers 400 MaxConnectionsPerChild 0
pm = dynamic pm.max_children = 400 pm.start_servers = 75 pm.min_spare_servers = 50 pm.max_spare_servers = 100
- MariaDB 10.0.0.19, with the following configuration:
performance_schema = OFF innodb_lock_wait_timeout = 120 default_storage_engine = InnoDB max_allowed_packet = 16M key_buffer_size = 128M table_cache = 4096 read_buffer_size = 2M read_rnd_buffer_size = 1M thread_cache_size = 80 join_buffer_size = 2M sort_buffer_size = 2M max_connections = 400 tmp_table_size = 32M max_heap_table_size = 32M table_definition_cache = 8192 query_cache_size = 32M innodb_buffer_pool_size = 3G innodb_log_file_size = 128M innodb_log_files_in_group = 2 innodb_log_buffer_size = 8M innodb_flush_log_at_trx_commit = 2 innodb_thread_concurrency = 32 innodb_read_io_threads = 8 innodb_write_io_threads = 8 innodb_flush_method = O_DIRECT innodb_file_per_table = 1 innodb_io_capacity = 2000 innodb_file_format = Barracuda innodb_buffer_pool_dump_at_shutdown = ON innodb_buffer_pool_load_at_startup = ON innodb_checksum_algorithm = crc32 innodb_log_compressed_pages = 0 # SSD innodb_flush_neighbors = 0 # Mutex contention innodb_adaptive_hash_index_partitions = 16 innodb_buffer_pool_instances = 16
We tested a real shop with:
- 1,827 categories
- 10,843 cart rules
- 1,904 products
- 2M product attributes
- 16.5M attribute combinations
When Memcached is used, it’s configured locally, with 128 MB of memory.
The single-threaded and multi-threaded benchmarks results are the average of 5 “siege -i -b -t 20S” (20s benchmark), on representative pages which have a direct impact on user navigation and SEO:
- Category pages
- Product pages
- Home pages
- Cart pages
- Best sales pages
- Tag search pages
- Manufacturer pages
- New product pages
- Price drop pages
- Supplier pages
- Search pages
First, the single-threaded performances:
It looks promising: up to 10x improvement when Memcached is On!
Let’s take a look at how the new 18.104.22.168 scales:
Even without any cache, 22.214.171.124 scales much better than 126.96.36.199, and is up to 65% faster with 15 concurrent connections.
If we enable the query cache, the 188.8.131.52 is still up to 50% faster with 10 concurrent connections.
Well, we definitely fixed the PrestaShop cache issue. We reach almost a 10x improvement with 10 concurrent connections!
Here are the performances side by side, at 10 concurrent connections:
Back office performances
Here are a few results from the back office.
Full search reindexing:
On the performance side, when Memcached is enabled, 184.108.40.206 times out after 900s, and eats more than 128 MB of memory. When Memcached is disabled, 220.127.116.11 is 2.3x faster than 18.104.22.168, eats 1.7x less memory, and fixes a bug with multi attributes. Not bad!
Although those results were not computed on the same machine, I decided to include them as well to show you the potential speed you could expect with the import in 22.214.171.124 (here almost a 5x speed up).
Now let’s measure the time to load some back office pages.
In our case, with 1,827 categories, 126.96.36.199 is 1.7x faster.
With 10843 cart rules, once again 188.8.131.52 is 1.7x faster.
184.108.40.206 is a major release in terms of performances, with up to 10x speed up in some cases.
To achieve those results we have worked really closely with the PrestaShop team, modifying about 6600 lines of code in a few months. We hope you’ll be happy with this version, and don’t hesitate to report any performance issues on the Forge!
Final note: Whereas in 220.127.116.11 we recommended to not enable the PrestaShop cache, in 18.104.22.168 we recommend you to enable it, with a local Memcached server (APC should be OK as well).