In this article you will learn how to get the maximum performance out of your store. For this purpose, we will give you some tips and tricks and tell you how to adjust various settings.
If you have advanced technical know-how, you can also find more information in our Developer Documentation. Performance Tweaks - Shopware Developer
Topic | Standard | Optimal | Info |
|---|---|---|---|
PHP-Version | - | FPM | PHP-FPM is a much more performant and modern solution to manage processes. |
Bytecode-Cache | APC | ZendOpcache + APCu | In any case, a bytecode cache should be installed and configured correctly - this speeds up the execution of the PHP stack by up to 25%. |
Database | >= MySQL 8 oder MariaDB >= 10.3.22 | >= MySQL 8 | Unless Elastic or OpenSearch is used, MySQL should be used instead of MariaDB. In some parts of the code we use JSON fields. As soon as it comes to filtering, sorting or aggregating JSON fields, MySQL is ahead of the MariaDB fork. |
Webserver | >= Apache 2.4 | NGINX | The architecture of NGINX makes it possible to perform better than Apache2 for stores with very high access numbers. |
Debug-/Profiling | - | - | Make sure that no profiling tools such as xDebug or XhProf are active on the production server - these significantly reduce the execution speed of PHP. Likewise, the Shopware Debug & Benchmark plugins should never be used in production operation. |
With each new Shopware release, performance improvements also flow into the development. Therefore, it is advisable to upgrade to the latest available Shopware version as soon as possible.
The hoster must fit the planned deployment scenario and should offer an upgrade path for the chosen hosting package so that it can grow along with the requirements. You should pay attention to the following points:
Shared hosting / VServer / Dedicated server.
Software stack should match our recommendations (see above)
Shopware experience available?
Shopware reference stores?
Basically we recommend to use one of our certified hosters. You can find a current overview under the following link: Shopware Hosting Partner
The specified loading times are only to be understood as an indicator, as they can vary depending on the number / structure of the store and the current traffic.
The following analysis steps should be performed in a test system, instructions can be found here.
deactivate all third party extensions without exception
Assign standard Responsive Theme
Empty & warm up cache
Check performance
If these steps have led to an improvement, it is important to eliminate the factors step by step. If there is still unsatisfactory performance, it is recommended to determine the following benchmark values:
How many items does the store have? How many variants?
How many categories does the store have? How many category assignments?
How many simultaneous accesses are there?
At what point does the poor performance become noticeable?
Can a time be defined here at which the problems occur?
To ensure that the results are comparable, it is recommended to use the Shopware Demo Data Package as a test basis. Then you can determine the individual loading times via the network console of your browser.
Relevant is the loading time of the page itself - this is usually the first entry in the list. Then call up the start page, listing and detail page 5 to 10 times each and determine an average value from the individual execution times.
Call via Linux shell:
ab -n 10 -c 1 http://www.domain.tld:80/{start page,category,listing}
Then take the median of the total time (connection times) as the value.
Task | Ansprechpartner | Info |
|---|---|---|
Identify problematic components | Customer / Hoster | Where exactly do performance bottlenecks occur? Web server, database server, PHP stack, etc. |
SQL Slow Query Evaluation | Hoster | Which database queries affect the overall performance of the store? |
Hosting platform analysis | Hoster / Customer | Is the hosting environment suitable for the size, traffic, of the store? Current / recommended server components in use? Dedicated server - No VHost or webspace package - No Shopware third-party applications running on the server? |
Connections | Kunde | Are large amounts of data regularly added / changed due to the connection to an ERP system? Are other tasks regularly executed on the store server that could affect performance? |
The default MySQL configuration of many distributions is not optimized for production use. The mysqltuner script provides clues as to which configuration parameters are not yet ideal.
wget http://mysqltuner.pl/ -O mysqltuner.pl
chmod +x mysqltuner.pl
./mysqltuner.pl
By default, Shopware 6 uses the Admin Worker. However, it processes the message queue more slowly than the CLI Worker and also requires the administration to be open for a longer period of time. Therefore, we recommend disabling it in two simple steps for production systems.
The following settings are made directly on the server. Since the possibilities of the server configuration depend on the hoster, we explain this here generally. If you have questions about the operation of the server configuration, the support of your hoster should be able to help.
In all new Shopware projects, there is only one lock.yaml file under config/packages/ in the installation. This can also be the case if you have carried out an update and the .yaml files under config/packages/ were not adjusted in the past.
If this is the case for you, you must create a new shopware.yaml file and insert the adjustments here!
To disable the admin worker you have to make the change in the z-shopware.yaml file. You can find it in your Shopware installation under config/packages/. Disable the admin worker by setting the value enable_admin_worker to "false" and save the file. Your file should now look like this:
# config/packages/shopware.yaml
shopware:
admin_worker:
enable_admin_worker: falseIn order for the Message Queue and the Scheduled Tasks to be executed now, the processes must be started via the CLI.
Message Queue:
bin/console messenger:consume default --time-limit=60
Scheduled Tasks:
bin/console scheduled-task:run --time-limit=60We recommend the parameter time-limit=60 for the above commands, so that the command is executed for a maximum of 60 seconds. Alternatively / additionally you can define a memory limit instead of a time limit, this is possible with the parameter --memory-limit=512M. More information can be found in our Developer Documentation.
It is important that the commands are executed regularly (e.g. every 60 seconds, see --time-limit) so that the message queue is processed continuously. This can be achieved, for example, by creating a cron job or a service on the server. Contact your hoster for this.
The use of the following three technologies probably has the greatest impact on performance. However, configuration and maintenance require specialist knowledge and are actually only needed in very large systems with a lot of traffic.
ElasticSearch or OpenSearch is an open source search engine and analytics solution specifically designed for fast and scalable search and analysis of large amounts of unstructured data.
You can find instructions on how to use ElasticSearch / OpenSearch in our Developer Documentation. Set up Elasticsearch - Shopware Developer
Shopware uses the session storage configured in PHP by default. For most installations, this is the file system. To reduce the load on the database and enable faster data processing, the use of Redis is recommended.
You can find instructions on how to use Redis in our developer documentation. Session - Shopware Developer
Flysystems allow you to store data securely, redundantly and performantly off-site. This can further reduce the load on your own server and provide better performance.
You can find instructions on how to use Flysystems in our developer documentation. Filesystem - Shopware Developer