The N+1 problem is the single biggest cause of Shopware API slow performance under load. It happens when a DAL query loads a list of entities but does not declare the associations it needs. Shopware then fetches each association with a separate query per entity.

Take 20 products with 3 associations each. That is 60 extra queries per API call. At 100 concurrent requests, this adds 6,000 extra DB queries per second on top of the base load.

The fix is eager loading. Shopware’s DAL Criteria object accepts ->addAssociation() calls before the query runs. These tell the DAL to JOIN and batch-load the related data in one round trip instead of N separate ones. This is the highest-leverage change available for Shopware API optimization.

To find N+1 issues, set APP_ENV=dev in your .env and open the Symfony web profiler on the API endpoint. The “Database” tab shows every query executed, grouped by entity. If you see the same query pattern repeating with different IDs, that is an N+1. The query count should be under 10 for any well-built endpoint.

• ✦Add aCriteriaEventSubscriberto log every Criteria object in production. This captures association patterns across all API calls without debug mode. Any Criteria with zero associations on a list endpoint is a candidate for the N+1 fix.
• ✦Only load associations you actually serialise in the response. Fetchingcategorieswhen the response only usescategory.nameis wasteful. UseaddAssociation('categories.translation')instead of the full category tree.
• ✦For product variants, useaddAssociation('children.prices')andaddAssociation('children.options')together. These are the most common missed associations on variant-heavy B2B catalogues.

Shopware’s Store API supports HTTP reverse proxy caching. When enabled, Shopware adds Cache-Control headers to cacheable responses. Varnish or a CDN stores the full JSON response.

The next request for the same endpoint gets the cached copy without touching PHP or MySQL at all. This is the fastest possible Shopware API performance fix for read-heavy endpoints.

Without caching, every product listing request — even for the same category, same filters, same page — runs the full PHP stack. At 300 concurrent requests, all 300 hit the database. With caching at a 95% hit rate, only 15 of those 300 requests reach PHP. The other 285 return in under 10ms from Varnish memory.

For custom API controllers, you must opt in to caching manually. Shopware’s built-in Store API routes use the #[Route] attribute with options=["seo" => false] and rely on the AbstractSalesChannelContext to vary the cache key. For a custom controller, add the HttpCache annotation and define the correct vary headers so the cache does not serve the wrong Sales Channel data.

• ✦Verify caching is working after enabling it. Runcurl -I https://your-store.com/store-api/category/{id}twice. The second response must includeX-Cache: HIT. If it still shows MISS, check whetherTRUSTED_PROXIESis set in your.envto trust your Varnish IP.
• ✦Do not cache endpoints that return user-specific data. Cart, wishlist, account, and any endpoint that reads the customer context must bypass the cache. Add the customer context token to thevaryheader or bypass Varnish entirely for those routes.
• ✦Use Redis for Shopware’s internal app cache too. SetREDIS_URLin.env. Without Redis, Shopware’s route cache, DI container, and template cache all live on disk. Under load, disk reads become a secondary bottleneck even when HTTP caching is active.

MySQL’s max_connections defaults to 151. Each PHP-FPM worker holds one connection for the duration of a request. If your PHP-FPM pool has 200 workers and max_connections is 151, you hit the ceiling at 151 concurrent requests.

The 152nd worker cannot get a connection. It waits. Shopware API slow responses appear as a sudden, hard performance cliff at exactly that concurrency level — not a gradual slowdown.

The right fix is not simply to raise max_connections. Each MySQL connection uses ~8MB of memory. 500 connections use 4GB of RAM just for connection overhead. The better solution is a connection pooler. ProxySQL sits between PHP-FPM and MySQL. It multiplexes many PHP connections onto a smaller number of real MySQL connections. 500 PHP workers can share 80 MySQL connections with ProxySQL in place.

• ✦Match your PHP-FPMpm.max_childrento your connection budget. A rule of thumb:pm.max_children = available_RAM_MB / average_PHP_worker_MB. For a server with 8GB RAM and 64MB per worker, setpm.max_children = 80. Then setmax_connectionsto at least 90 to give headroom.
• ✦Setwait_timeout = 60. Without this, idle PHP workers hold open MySQL connections indefinitely. On a busy server, this wastes your entire connection budget on workers that are doing nothing. Short timeouts free connections back to the pool within a minute.
• ✦MonitorThreads_connectedin real time during Shopware load testing. Add it to your Grafana dashboard or check withwatch -n1 "mysql -e 'SHOW STATUS LIKE "Threads_connected";'". When it approachesmax_connections, you need either a pooler or a tighter PHP-FPM configuration.

PHP uses file locking for session reads and writes. When two requests from the same session arrive at the same time, the second blocks until the first releases the lock. On a storefront with persistent sessions, this creates queue points that are invisible in single-user testing.

Under load, many workers sit waiting for session file locks. Shopware response time spikes without any query count change.

Redis uses atomic operations. No file locking. No queue. 200 concurrent session reads complete in parallel. Moving sessions from disk to Redis is one of the fastest wins available for Shopware API performance under load. It also removes session data from the filesystem entirely, which helps if you ever need to scale to multiple PHP servers.

• ✦After moving sessions to Redis, run the confirmation command above. The key count should grow as users browse the store. If it stays at zero, Shopware is still writing to disk despite the config change. Check that you ranphp bin/console cache:clearafter updating the framework config.
• ✦Allocate at least 512MB to Redis for a live Shopware store. Use theallkeys-lrueviction policy so Redis frees old sessions on its own when memory pressure rises. Without an eviction policy, Redis returns an error when full — which breaks Shopware sessions entirely.
• ✦Use a separate Redis database (or separate instance) for sessions vs the Shopware app cache. Session data has short TTLs and high churn. App cache objects are long-lived. Mixing them causes the LRU eviction to clear valuable cache objects when sessions fill up memory.

Shopware’s product table can hold hundreds of thousands of rows. An API endpoint that filters by a column without an index performs a full table scan on every request. A full scan on 200,000 rows takes 200 to 800ms — on top of every other query in the call.

Under load, slow scans pile up and block other queries waiting for table read locks. The entire Shopware API performance degrades — not just the slow endpoint.

Custom fields stored in the Shopware custom_fields JSON column are a common problem source. You cannot add a standard index to a JSON column path. The query optimiser cannot use a JSON path expression as an index. The solution is a MySQL generated column — extract the value into a real column, then index it.

• ✦Setlong_query_time = 0.5during load testing — not 1 second. Queries taking 500ms are already a problem under load. Catching them early gives you a more useful slow query log to work from.
• ✦Usept-query-digestfrom Percona Toolkit after your load test. It reads the slow query log and ranks queries by total cumulative time. This immediately shows which query is costing the most across the full test run — not just the worst single execution.
• ✦After adding an index on a large table, usept-online-schema-changefor the ALTER. StandardALTER TABLElocks the table during index creation. On a 200,000-row product table, this can take 30 to 90 seconds.pt-oscbuilds the index on a shadow table and does a fast atomic swap — zero downtime.