Slow Shop Backend: Speeding Up the Admin for Your Team

The Shopware admin is an application that runs in the browser and fetches every list, every search and every save from the server via the Admin API. These requests usually end up in the same PHP process pool as your customers’ page views. There, the pm.max_children setting limits how many requests are served at the same time (PHP manual). Once all processes are busy, the next request waits, regardless of whether it comes from a customer in checkout or from a colleague in the orders module.

The same perception limits apply to the admin as anywhere else: up to about 0.1 seconds (Nielsen Norman Group 1993), a reaction feels instantaneous. Up to about 1 second (Nielsen Norman Group 1993), the flow of thought stays uninterrupted, even though the delay is noticeable. From about 10 seconds (Nielsen Norman Group 1993), attention drifts and people start doing something else on the side. For the response to a click, an INP of 200 milliseconds (web.dev) or less counts as good. An order list that needs several seconds after every filter change is far beyond what feels smooth.

In everyday work, this rarely stands out as a single event. It shows up as a sum: the list takes a little longer to load, saving drags on, the search reacts late to the input. Anyone who touches many orders a day loses these seconds over and over again. And because the admin uses the same server as the shop, an overloaded admin can also worsen the response time of the storefront.

For production systems, the documentation recommends processing the queue via the command line. Tasks are then completed even when nobody is logged in, and the high CPU load caused by several people in the admin goes away (Shopware documentation). The switch has three parts: run the workers as a service, switch off the admin worker, and trigger scheduled tasks separately.

The workers themselves run as a service that systemd or Supervisor restarts as needed. The documentation provides a systemd template from which several identical instances can be started, plus a target unit that starts them together. Each worker exits after a fixed runtime or when it reaches a memory limit, in the documentation’s example after 60 seconds (Shopware documentation). The service then starts it fresh. That is intentional: Symfony advises against letting workers run forever and gives the example of a restart after 10 messages (Symfony documentation), because some services accumulate memory over time.

How many workers make sense depends on the type of messages. Product indexing usually runs slowly, while other messages are processed quickly (Shopware documentation). From Shopware’s experience, up to three worker processes (Shopware documentation) are normal and useful in production. Anyone who needs more moves the queue out of the database into a dedicated queue system so that the database does not become a bottleneck. Long indexing messages can also be routed to a separate transport so that they do not hold up urgent tasks such as sending mail.

Two points belong in every deployment. Once the new code is in place, messenger:stop-workers ends the running workers cleanly so that they restart with the new version (Symfony documentation). And the switch does not make the server load disappear; it makes it plannable. How to size the PHP process pool for that is described in the article on OPcache, JIT and FPM workers.

In the Christmas season, the order list and the product list are among the views opened most frequently. Their speed depends less on the number of rows on screen than on the query behind them. Every column that shows data from a linked table, such as manufacturer, customer group, shipping method or custom fields, can mean an additional association in the query. Extensions that hook their own columns or filters into lists make the query larger still.

The total count is expensive as well. A list with page numbers needs to know how many hits there are in total. The Admin API offers several modes for this: no total, an exact total, or only the information whether there is a next page. The documentation describes the exact count as performance-intensive and the other two modes as fast (Shopware documentation). For your own lists in extensions and for interfaces that only page through results, the mode “is there a next page” is often enough.

Where a list stays slow despite lean columns, the cause can lie in the database itself: filters on custom fields stored in JSON columns, large tables without cleanup, locks caused by parallel writes. How to find and speed up such queries is shown in the article on database query optimization.

Some work cannot be avoided, but it can be moved. A full rebuild of all indexes creates messages for every single record, triggered via the command line or via the corresponding button in the admin settings (Shopware documentation). Anyone who starts it on a November morning lengthens the waits in the team until the queue is empty. For the whole shop, the documentation recommends dal:refresh:index with the --use-queue option so that the work runs through the queue; the right time for it is at night.

Then there are scheduled tasks. By default, Shopware generates the sitemap once a day; the list of default tasks gives an interval of 86,400 seconds (Shopware documentation) for it. With large catalogs, this task can occupy the queue for a long time and hold up other tasks. Since Shopware 6.7.1.0 (Shopware documentation), the scheduled sitemap generation can be switched off and started via cron at a quiet hour. The task for product exports appears in the same list with an interval of 60 seconds (Shopware documentation); anyone who maintains many exports checks their individual intervals.

Another candidate is the indexer for dynamic product groups. It maintains a mapping of products to their groups and can become a bottleneck with large assortments or frequent changes. Since Shopware 6.6.10.0 (Shopware documentation), it can be switched off. The price: category pages with dynamic product groups only show a product change once the HTTP cache expires, and the rule condition for line items in dynamic product groups then evaluates to “false” throughout. This is a trade-off for shops that maintain a lot and use few dynamic groups, not a default setting.

Which of these points slows your shop down can only be shown by a measurement during working hours. A measurement on a Sunday evening with a single logged-in person finds neither the admin worker nor the locks that only appear with several workers. What makes sense is a measurement window on a normal working day, with the roles that actually work: customer service, shipping, product maintenance.

These values produce a small table per view: order list, product list, search, saving a product, upload. Each row has a baseline before the switch and a value afterwards, measured under comparable load. Anyone who also wants to know before the Christmas season how much concurrent work the server can carry adds a load test that loads the admin and the shop together. A performance analysis provides the baseline for it.