PrestaShop a new level of performances

I) What's new in PrestaShop

A lot of things have been improved on PrestaShop :
  • Design
  • Invoices
  • Search
  • Performance : 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.

II) Which parts of PrestaShop are faster?

1) Faster single-threaded performances

Thanks to our internal tools (to be publicly released soon!), we quickly identified the bottlenecks of PrestaShop which were impacting directly the generation time of the pages, and hence the SEO and the user satisfaction. At the PHP level, without the cache activated, after launching a crawl on a real shop, we collected all the datas we needed in a few minutes : php_bottleneck Same at the SQL level : bottleneck 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.

2) Faster multi-threaded performances

Beside the huge work on the query performances, we have worked a lot on the SQL queries to make sure to efficiently use the MySQL query cache, and we 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 not the case anymore!

3) 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 sped up a lot all the back-office operations!

4) Better backoffice performances

We removed the most frustrating bottleneck in the PrestaShop backoffice :
  • 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.

III) Let's bench!

1) The configuration

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 : 64GB
  • Disk : 2x SSD 600GB
  • 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
  • PHP 5.6.7 & APCu + Zend OpCache v7.0.4-dev in PHP-FPM mode with the following configuration :
pm =                    dynamic
pm.max_children       = 400
pm.start_servers      = 75
pm.min_spare_servers  = 50
pm.max_spare_servers  = 100
  •  MariaDB 10.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
innodb_flush_neighbors                = 0
# Mutex contention
innodb_adaptive_hash_index_partitions = 16
innodb_buffer_pool_instances          = 16
We benched a real shop with :
  • 1827 categories
  • 10843 cart rules
  • 1904 products
  • 2M product attributes
  • 16.5M attribute combinations
When memcached is used, it's configured locally, with 128MB 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 users 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

2) The results

a) Front performances

First, the single-threaded performances : Prestashop : Single-threaded performances   It looks promising : up to 10x improvement when Memcached is On! Let's take a look at how the new scales :

 Prestashop : Multi-threaded performances with Query Cache and Memcached disabled

Even without any cache, scales much better than, and is up to 65% faster with 15 concurrent connections.   Prestashop : Multi-threaded performances with Query Cache enabled and Memcached disabled   If we enable the query cache, the is still up to 50% faster with 10 concurrent connections.   Prestashop : Multi-threaded performances with Query Cache enabled and Memcached enabled   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 :    

b) Backoffice performances

Here are a few results from the backoffice.

Full search reindexing :

On the performance side, when memcached is enable, timeout after 900s, and eat more than 128MB memory. When memcached is disabled, is 2,3x faster than, eat 1,7x less memory, and fix a bug with multi attributes. Not bad!

Import speed :

Although those result were not computed on the same machine, I decided to include this as well to show you the potential speed you could expect with the import in (here almost a 5x speed up).   Now let's mesure the time to load some backoffice pages.

Product edit :

In our case, with 1827 categories, is 1.7x faster.

Cart rules :

With 10843 cart rules, once again is 1.7x faster.

III) Conclusion is a major release in term 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 Note whereas in we recommend to not enable the PrestaShop cache, in we recommend you to enable it, with a local memcached server or even better, an APC cache. To be sure to get the best performances, we also recommend you to run an ANALYZE TABLE on your Prestashop database after upgrading to (the MySQL command is : mysqlcheck -a)
  • Anto


  • I upgraded to 1.6.1 from 1.4 and I was amazed, well done!

    Would you recommend enabling the smarty mysql cache when using mariaDB 10?

    Which cache option would you recommend (memcache, memcached or apc)?

    • Do not use the smarty mysql cache 🙂
      As for the cache option, it depends. If mysql & the webserver is hosted on the same machine, do not enable any cache, and enable MySQL query cache instead. However if mysql is installed on another machine, you’d better use apc to save a few network roundtrips (but keep MySQL query cache enabled in both cases).