Shopware Audit

Role: Consultant
Year: 2020
Technologies: Shopware 5, PHP, MySQL, Redis

Independent performance audit of a Shopware 5 storefront — isolating MySQL, caching and PHP bottlenecks and delivering a prioritised, evidence-based optimisation roadmap.

The challenge

A Shopware 5 storefront that performed superbly while cached (0.11s) but collapsed to 17s under concurrent load whenever requests hit PHP and MySQL directly.

My role

Independent performance audit: captured the full PHP/MySQL/hosting configuration, benchmarked cached vs. uncached load under concurrency, and delivered eight prioritised, evidence-based recommendations.

The outcome

Identified the oversized MySQL query cache as a primary culprit and handed over a prioritised roadmap — quick wins plus PHP 7.4, IonCube removal and a multi-node scaling path.

Context

CULTIZM, an established online retailer, ran their business on Shopware 5.2.12 with PHP 7.0 and MySQL 5.7 on a single high-powered server (32 cores, 93 GB RAM). Under normal conditions with the HTTP cache active, page load times were excellent — the homepage rendered in 0.11 seconds. But whenever the cache was bypassed, performance collapsed: product detail pages took over 3 seconds, and under concurrent load, response times climbed as high as 17 seconds. The underlying cause was not obvious, and the client needed an independent, data-driven assessment.

Challenge

The core challenge was the stark disparity between cached and uncached performance. As long as the HTTP cache absorbed the traffic, the shop ran smoothly. But any request that hit PHP and MySQL directly — browsing the cart, checking out, or running a search — experienced severe slowdowns. Potential causes spanned multiple layers: an outdated PHP version, inefficient MySQL configuration (notably an oversized 128 MB query cache), lack of scalability from the single-server architecture, and the mandatory IonCube encoding that blocked modern PHP features. The task was to isolate the real bottlenecks from these contributing factors and deliver a prioritised action plan — without disrupting the live operation.

Approach

I conducted a systematic, multi-layered analysis. First, I captured the full infrastructure configuration: PHP settings (OPCache, execution limits), MySQL parameters (query cache, InnoDB buffer), and the hosting model. I then measured actual load times across all relevant page types — both with and without the HTTP cache. Apache Benchmark tests simulated concurrent access under load, revealing MySQL locking behaviour. Each finding was documented with measurable baseline values, mapped to a root cause, and assessed for effort and expected benefit. The final report presented eight prioritised recommendations in a clear action matrix.

Outcome

The analysis identified the MySQL query cache as a primary culprit: oversized at 128 MB, it caused massive blocking during write operations. Further quick wins included migrating session storage to Redis and optimising the PHP OPCache configuration. For the medium term, the report recommended upgrading to PHP 7.4 and removing the IonCube loader, which prevented the use of modern PHP features and OPCode optimisations. To support scalable growth, a migration to multi-node hosting with a load balancer and MySQL cluster (primary plus replicas) was outlined. The client received a clear, evidence-based roadmap combining rapid stability gains with a sustainable architectural direction.